Core10: Namespace Global

[This post is part of a series, "wish-list for future versions of VB"]

IDEA: "Namespace Global". Allow people to declare "Namespace Global" so that their code goes into the global namespace, rather than always being inside the Project>Properties>RootNamespace.

SCENARIO: A partner team within Microsoft is writing a designer. This designer does code-gen. It wants to emit a type inside the "System" namespace. However this is currently impossible, since all emitted code goes inside the project's root namespace. If we allowed "Namespace Global" then we could do it:

Namespace Global

    Namespace System

        Class Fred : End Class

    End Namespace

End Namespace

We've not had requests from end-users to add this feature. (Tthere seem to be few users who write their own general-purpose code generation). But we've had many requests from other groups within Microsoft.


Provisional evaluation from VB team: This is a decent idea, one that we should consider against the other decent ideas.

Comments (6)

  1. Dzonny says:

    So, let me be the first end user requesting this 🙂 I really like the idea, and I have missed this functionality a few times.

    For example imagine that I have assembly named Tools.Windows.Forms. Naturally the root namespace is Tools.Windows.Forms. Now I need to implement some class that in fact is not WinForms specific and will be possibly in feature recaftored to more appropriate assembly. Without this feature I have to either remove root namespace of project and type namespace in each file manually (so C#ish) or implement the class i.e. FileSystemProvider under Tools.Windows.Forms.

    And two small thinks

    * Make

    Namespace Global.System

    possible too. I prefer it over

    Namespace Global

       Namespace System

    * Make Global blue in editor (keyword) 😉

  2. Damien says:

    Definitely – I sometimes find that I’m 80% done with building a project, and then find that I want to add another class file in a different namespace – but there’s no way to "escape out" from the Project Root. So I have to go through the pain of re-namespacing all of my existing classes to try and achieve this.

  3. Kevin Ryall says:

    This is something that has caused me pain quite a few times – I do quite a bit of code generation with T4 templates, and to work around this lack I have blank the project namespace and explicitly specify the namespace on each file – a pain when it ‘costs me’ an indentation block.

    Incidentally, I’m not sure what you mean by saying that you’ve not had requests form end users for this feature? How exactly are end users supposed to request features from you? I’ve encountered many limitations that I would regard as missing features (or even bugs), and I’ve never been aware of ANY way of reporting them to Microsoft. No-one I’ve asked (an admittedly small sample) has any idea how to do this either, so I’m not sure how you can realistically measure the demand for features if no-one is communicating with you?

    Anyway, you can count me as at least one customer requesting this feature.

  4. Héctor says:

    This is something I’ve also wanted sometime in the past.

    As the upper poster, I also realized back in the day that leaving the root namespace field blank "sets" the assembly in the global namespace, although there should be a better way to do this, like the one described.

  5. Rowland Shaw says:

    One scenario that would be useful would be when importing webservices.

    As an example, we have an internal webservice for handling transport routing, that we wanted to use from our Costing application; selecting "MyCompany.Transport.Routing" as the target namespace ends up putting it in "MyCompany.Transport.Costing.Windows.MyCompany.Transport.Routing".

    Whilst it works, it’s not the behaviour I expected.

  6. weitzhandler says:

    I posted a Connection about it a couple of months ago, please vote and comment.…/allow-escaping-to-the-global-namespace-scope-in-vb-net.

    Thanks for the blog.

Skip to main content