Fully qualified names

  • Thread starter Thread starter fc2
  • Start date Start date
F

fc2

Hi

I have a problem with fully qualified names. According to the C#
language specification:

"Every namespace and type has a fully qualified name, which uniquely
identifies the namespace or type amongst all others."

However, I have problems compiling the following:

namespace Foo.System.Bar
{
class Program
{
static void Main(string[] args)
{
System.Console.WriteLine("Hello, World");
}
}
}

With compiler output:

"The type or namespace name 'Console' does not exist in the namespace
'Foo.System' (are you missing an assembly reference?)"

Changing the namespace name from "Foo.System.Bar" to "Foo.Sys.Bar"
solves
the problem so I guess it has to do with the rules for resolving types
(they are rather unclear in the language spec.).

The bottom line is that I'm unable to access System.Console in my
program
even when using the fully qualified name. I wonder if this is a
compiler
bug or expected behaviour?


/fc2
 
Try this instead:

using System;

namespace Foo.System.Bar
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello, World");
}
}
}

/Joakim
 
Ok, but still I ought to always be able to use the fully qualified name
(to explicitly state my intentions).

The situation is further complicated by the fact the MS VS .NET
generates some classes behind my back (for accessing resources and for
settings). The generated code uses fully qualified names to system
libraries and this code won't compile either (unless i change it
manually which is a no-no) since it also tries to find system classes
inside Foo (probably because they are part of the same compilation
unit).


/fc2
 
This is addressed in C# 2.0 - you can write
global::System.Console.WriteLine().

HTH,
Stefan
 
OK, I hate to recommend this, but...

Can you change your namespace, in your app, so that the word "System" is not
part of it?

I guess my thinking is this: we work around "reserved words" all the time.
You ran into one in a place you didn't expect, but that doesn't mean you
can't work around it in the same way. I'm not making excuses... perhaps my
perspective is just different.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
 
Back
Top