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).
'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.