What is wrong with my namespaces?

I am in the process to rename the namespace in our project. I found a strange thing and cannot understand why is that?

Original structure:

namespace Mycompany.Util
{
    public class Util{
        public static void ReadDictionaryFile()
        {
        }
    }
}

in another file

using MyCompany.Util;

namespace Logging {
    public class Log {
        public void Met开发者_C百科hodB() {
            ...
            Util.ReadDictionaryFile();
            ...
        }
    }
}

above works fine, no compile error.

Then I change the Logging namespace to MyCompany.Logging, I get error in MethodB immediately telling me

"Error 5 The type or namespace name 'ReadDictionaryFile' does not exist in the namespace 'MyCompany.Util' (are you missing an assembly reference?) C:\workspace\SystemSoftware\SystemSoftware\src\log\Log.cs 283 61 SystemSoftware
"

I have to change that function call from Util.ReadDictionaryFile() to MyCompany.Util.Util.ReadDictionaryFile() I don't know why? Is there another Util class in the system library?

The entire using lines are followed:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using MyCompany.Util;

Edit:

In C#, when we call a static method, we have to call like this: namespace.classname.methodname? Ok, I just come from Java. In Java, after you use import MyCompany.Util.*; you can call static method with this format: className.methodName;, no package name is required.

Edit2:

C# and Java are the same, className.methodName; is enough to call static method if we use namespace correctly.

---

MyCompany.Util.Util.ReadDictionaryFile()

This is namespace.namespace.class.method, as defined in your first code block.

And yes, as mentioned, the typos probably didn't help matters.

Edit: This code sample compiles fine.

namespace MyCompany.Util
{
    public class Util
    {
        public static void ReadDictionaryFile()
        {
        }
    }
}

namespace MyCompany.Logging
{
    using MyCompany.Util;

    public class Log
    {
        public void MethodB()
        {
            Util.ReadDictionaryFile();
        }
    }
}

If I take out the using directive, then I have to fully qualify the namespace, unless the default namespace is MyCompany, in which case you only need to qualify the Util namespace, Util.Util.ReadDictionaryFile().

---

The problem is that, when you add the parent namespace MyCompany to Logging, the compiler resolves Util to be the Util namespace in the MyCompany namespace rather than the Util class in the MyCompany.Util namespace.

---

In the context of your Log class inside MyCompany.Logging namespace, Util on its own refers to the Util namespace under the MyCompany namespace. Instead of MyCompany.Util.Util.ReadDictionaryFile(), your could also write Util.Util.ReadDictionaryFile(). You've created an ambiguity between a namespace and a class, and in the context of your usage, it resolves to the namespace first.

You could change MyCompany.Util to MyCompany.Utilities. Or you can change your using statement to give the Util class an alias, such as:

using Utils = MyCompany.Util.Util;

//usage
Utils.ReadDictionaryFile();

---

You should fix the problem by not causing it in the first place. Never give a class and its namespace the same name. The Framework Design Guidelines explicitly call out that this is a terrible programming practice. Do not violate the Framework Design Guidelines; that's a recipe for pain.

The reason it is a terrible practice is because it leads to situations where the compiler cannot disambiguate when you mean the namespace or the type; it always picks one or the other, and frequently it picks the one you don't want.

Avoid, avoid, avoid.

---

OK, I'll answer it....

using MyCompany.Util;

namespace Mycompany.Util
{
 ...
}

// does not exist in the namespace 'MyCompany.Util'

You see the difference?

Edit: Even if this not the problem, your typos are making it hard for anyone to answer your question. You have to be precise. In academic circles you would probably not even get response to a question like this.