views:

709

answers:

4

Using .NET 2.0, C#, Windows Forms development, Enterprise Library 3.1.

We have a project namespace (call it Project). We also have several sub-namespaces inside of that project, for example Project.Namespace1, Project.Namespace2, etc.

In one class, we define enums and such to be used with the Enterprise Library Logging block, like this:

namespace Project.Logging
{
  public static class Logging
  {
    public enum LogPriority
    {
      // enum values here
    }
  }
}

In another class, I use the enum values so I need to declare a using statement. Same project, so there is no assembly to reference, right?

If I declare the using inside of the local namespace, like this, it works fine:

namespace Project.SomeName
{
  using Project.Logging;

  // code referencing the Logging enum
}

However, if I put the using statement outside of the local namespace declaration, I get the "type or namespace name 'LogPriority' does not exist in the namespace 'Project.Logging'... Like this:

using Project.Logging;

namespace Project.SomeName
{
  // code referencing the Logging.LogPriority.whatever
}

Why is this? Has anyone run across this before?

A: 

Yes, most likely you have an unusual value set for the "Default Namespace" in your project properties. I would validate the project configuration.

Mitchel Sellers
The default namespace is 'Project' (following the example I posted earlier), so that's not likely to be it. Great idea, though.
DaveN59
A: 

It definitely can make a difference if you have usings inside or outside the namespace. There is a good discussion here, and it is likely to be related to your default namespace settings.

Otávio Décio
That write-up was exactly what I was looking for. We also use StyleCop, and it was complaining about that. Prior to this gig, I had never heard of / used StylecCop, so it never dawned on me to put the using directives inside the namespace.
DaveN59
This answer doesn’t mention that the original problem was caused by a class having the same name as its namespace.
Timwi
+1  A: 

I have run into similar (though not exactly the same) problems before when using a class that has the same name as its namespace.

Oddly enough it seemed to compile ok on some developers pc's but not on others. In the end we made sure that no namespace contained a class of the same name.

namespace Project.Logging
{  
  public static class Logging  // this is what caused the probems for me
  {   

  }
}
dice
This is definitely something to watch for. That doesn't seem to be the problem here, but it is certainly possible it could create a real problem sometime later.
DaveN59
Basically, don’t name a class the same thing as the namespace it’s in, then the problem goes away.
Timwi
A: 

We ran into this issue before and it all went down to ambiguous naming of the namespace and the class name.

When we tried to have our namespace as Services.Web.xxx and also add in a service reference as Services.Web.xxxx and ALSO add a references to an assembly that was named Services.Web.xxx you can only imagine the problems we ran into.

In the end to fix it we simply did a rename to make sure that there was only one instance of the Services prefix

Also you could do the following and create an alias to LogPriority to LogEnum:

using LogEnum= Project.Logging.Logging.LogPriority;

namespace Project.SomeName
{
    internal class MyClass
    {
        public MyClass()
        {
            LogEnum enum1 = LogEnum.None;
        }
    }
}
namespace Project.Logging
{
    public static class Logging
    {
        public enum LogPriority
        {
            None,
            Default
        }
    }
}
Mark