C# Namespace Alias - What's the Point

C# namespace alias - what's the point?

That is a type alias, not a namespace alias; it is useful to disambiguate - for example, against:

using WinformTimer = System.Windows.Forms.Timer;
using ThreadingTimer = System.Threading.Timer;

(ps: thanks for the choice of Timer ;-p)

Otherwise, if you use both System.Windows.Forms.Timer and System.Timers.Timer in the same file you'd have to keep giving the full names (since Timer could be confusing).

It also plays a part with extern aliases for using types with the same fully-qualified type name from different assemblies - rare, but useful to be supported.

---

Actually, I can see another use: when you want quick access to a type, but don't want to use a regular using because you can't import some conflicting extension methods... a bit convoluted, but... here's an example...

namespace RealCode {
    //using Foo; // can't use this - it breaks DoSomething
    using Handy = Foo.Handy;
    using Bar;
    static class Program {
        static void Main() {
            Handy h = new Handy(); // prove available
            string test = "abc";            
            test.DoSomething(); // prove available
        }
    }
}
namespace Foo {
    static class TypeOne {
        public static void DoSomething(this string value) { }
    }
    class Handy {}
}
namespace Bar {
    static class TypeTwo {
        public static void DoSomething(this string value) { }
    }
}

What is the benefit of using namespace aliases in C#?

As everyone else has said, it is useful for disambiguating types when you have to import multiple namespaces at the same time.

This seems to be against other people's opinions, but it may also be useful for clarifying scope between two domains:

using Gilco.Test.ProjectX;
using DevCode = Gilco.Nilfum.Alpha.ProjectX;

public class MyTests
{
    public void TestCase1()
    {
        var car = new DevCode.Car();
        var testCar = new TestCar();
    }
}

It may also be useful in the rare case when you have to specify the namespace (for disambiguation), your namespace isn't so long to justify the alias, but is likely to change soon (like when you're using namespaces to support two versions of your code path simultaneously):

using DevCode = Gilco.V1;

Why does adding a namespace alias in C# remove ambiguity?

I think your misconception is that you believe that aliasing automatically imports the types of a namespace.

using Fourth.Fifth.Sixth;

makes all types in this namespace visible without additional qualification.

using MyAlias = First.Second.Third;

does nothing besides giving the namespace a new name, without importing it. So, if you change using First.Second.Third; into using MyAlias = First.Second.Third; the ambiguity is removed because Thing from First.Second.Third is no longer visible without further qualification. But obviously the other using is still importing Thing from Fourth.Fifth.Sixth.

Also see the corresponding definitions in the C# 5.0 Language Specification:

A using-alias-directive (§9.4.1) introduces an alias for a namespace
or type.

A using-namespace-directive (§9.4.2) imports the type members
of a namespace.

Type/Namespace alias conventions in C#

Namespace aliases are not a common feature of most code bases - the last place when I have used it, the senior developer was unfamiliar with it, though having worked with C# for many years.

Since it is rare, conventions have not been developed for it.

I would say that if you are going to use aliases, discuss this with your team to create your own convention.

Several different ways I have seen aliases used:

• An acronym of the namespace. Usually the capitals in the namespace.
• The very end of the namespace - if plural de-pluralized.
• A descriptive short name.

C# Namespace Alias qualifier (::) vs Dereferencing Operator (.)

This is a corner case :: (like the @ prefix) is there to deal with the fairly rare occurrences where a name conflicts between namespaces, classes and keywords.

:: only works for namespaces (and namespace aliases), while .. works for both namespaces and subclasses. Most places where you'd need it you'd be better off using a different name instead, but that isn't always an option.

global:: is a special case that's most often seen in auto-generated code - it resets the referenced namespace to the root.

For instance, suppose you auto-generate some code (maybe for a forms app, EF, or similar) and your app uses the namespace YourCompany.Application. Now one of your customers (using your auto-generation) decides to add their own namespace in their app TheirCompany.YourCompany.Application. Now all your auto code fails because when it compiles .Net doesn't know whether to use your namespace or theirs.

To fix this generate code with global::YourCompany.Application, then those that use your auto-generator can use whatever namespace they like and not conflict.

I think Microsoft added global:: because they expected some .Net customers to add namespaces like System.

Naming Conventions and Namespaces

I'd use namespaces and namespace aliases, e.g:

Define your classes in appropriate namespaces:

namespace Project1.Data
{
    public class Person {...}
}
namespace Project1.Model
{
    public class Person {...}
}

And where you use the classes, either use fully qualified names or define an alias for the namespaces (especially usefule if the full namespace is long):

using data = Project1.Data;
using model = Project1.Model;

data.Person p1 = new data.Person();
model.Person p2 = new model.Person();
//...
p1.Name = p2.Name;

Variable using declaration, namespace alias, using directive

This is a using directive also called an namespace alias.

If you have two types of the same name but from different namespaces, you need to spell out the namespace every time you use that type. If it's a long namespace, you may want to give it an alias.

---

Related Topics