ISerializable - Roy Osherove's Blog

I don't think that this repros in C#. VB must behave different in C#. C# is explicit; the root namespace does not affect how code is compiled in C#.

In my projects, the namespace you write is the same as the namespace you ultimately get regardless of the root namespace. global in C# works differently from what you mentioned here. The root namespace is the default name emitted in source files; otherwise typing namespace X.Y if the root namespace is X would yield X.X.Y.

The problem that globals solve in C# is when you define a namespace X.System and System automatically defaults to the nearest enclosing scope rather than the top level namespace. A root namespace is never automatically inserted before a namespace.

By automatically prefixing namespaces, VB is likely trying to be different from C# in order either to hide the concept of namespaces from VB programmers or to retain source compatibility with earlier versions.

Wesner: I've added to the post a repro in C#.

This is a good example of where C#'s explictness comes in handy. In the C# repro, it's much clearer that what you're doing is defining a System namespace under the ConsoleApplication1 namespace, and not referring to the global System namespace.

The UNCLEAR point, in C# as well as VB, is the scoping rules that say that the compiler always evaluates namespaces from the inside out. It will start at the current scope and go up the namespace hierarchy until it finds a namespace that matches the requests namespace (in this case System) and looks for the typename there.

I do admit that if I hadn't heard Juval Lowy explain this precise feature a few months ago, I would have been as stumped as you are. :)

is it even a good practice to "extend" on the .NET framework namespaces?

Excuse me for being an ass about it, BUT isn't the whole idea of namespaces is to make sure no on steps on each other?

Even if I wanted to extend the .NET framework I would never use the same namespaces, ever.

I would probably use something like MyCompany.System.Compoenet or something like that.

Sure, it might mess up the fact that I might (and that depends on my using statement in C#) have to alias System (the .NET System namespace) and call it DotNetSystem or something, but its reasonable and is understandable and has been like this since VS 2002.

It’s not easy to post your own mistake
(Even when you right about the bad indication)
You’re doing great community job by having
The courage to post such things
TNX

most of the time, yes. But sometimes you'd like to add an ability on an existing component and using the same namespace.
Besides, jsut suppose this was by accident. It's still almost impossible to realize your mistake.

I was really worried about this 'bug' when I first heard about it. But to be honest, I would never dream of writing:-

namespace ConsoleApplication167
{
namespace System
{
}

// etc.
}

And if problems did arise, I would *immediately* suspect my nested namespace definition of "System", and get rid of it. However, I think that overall there is reasonable evidence that the IDE is not quite ready for full-on production use, and will wait for a Service Pack. "Be neither the first to adopt the new, nor the last to relinquish the old."

I learned this same lesson 30 minutes ago. I have not found that easy-to-find help topic you mention. I had to guess myself that the namespace I declared inside code were appended to the root namespace of the project. I am ok with the fact that this is a defined behavior in VB, however, I am not convinced that there is no bug in the way this hides previously defined namespaces.

For instance, I have a project like this:

references: Company.dll wich is a company wide component that embedes some classes in the "Company" namespace (I know this is not a good practice, but this is our legacy).
root namespace: Company.Application

namespace Company.Application.Process
'this actually creates Comapny.Application.Company.Application.Process
class1
sub method1
end sub
end class1
end namespace

'this second class is not wrapped in a namespace, only root namespace is used
class2
sub method2
dim a as Company.frameworkClass1
'this cannot resolve to a class that is located in the Company.dll
'Intellisense shows that at this stage that only
'Company.Application.Process is visible. I have to resort to
'Global.Company.frameworkClass1
end sub
end class2

Of course this is not what I was tryin to do. I should define namespace Process and not namespace Company.Application.Process because Company.Application will be appended anyway. In the end, I would like Microsoft to allow a definition like this:

namespace Global.Company.Application.Porcess

or even

namespace Global

This would would be a nice way to bypass the root namespace. In my view the root namespace should be a convinience feature to reduce the ammount of code for the assembly, not such a hard restriction you cannot choose to include something that is out of the root namespace in the same assembly.

Make sense?