Develop Reference

Explanation of the 'using Namespace' directive [duplicate]

This question already has answers here:
Importing nested namespaces automatically in C#
(7 answers)
Closed 7 years ago.
Whenever, I start a new project in C#, I get the following:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
Why does using System; not allow you to use the sub namespaces with just the one line? I'm looking for an underlying reason as to why this isn't allowed. In the example given in the answer by HuorSwords:
namespace First {
class A { }
}
namespace First.Second {
class A { }
}
I would still get an error if I do:
using First;
using First.Second;
function void Test()
{
A variable;
}
I would still have to differeniate between the two. So then why am I forced to declare both namespaces instead of just the one? Aside from potential ambiguity, is there any other reason why we have to declare each namespace like this?

Think about this situation:
namespace First {
class A { }
}
namespace First.Second {
class A { }
}
If the behavior could be as you propose, then when you reference First namespace declaring a using First; sentence, and declares a variable of class A, how the compiler can deduce what of your two A classes should be used?
You can reference any type without using any using sentence, just putting the full namespace reference when you declare the variable.
var firstA = new First.A();
var secondA = new First.Second.A();
Then, when you try to import two or more namespaces that contains classes equally named, the compiler raises an error in order you can specify what class should be used.

Why I have to write the namespace to access to this extension method?

I have a project that has class to implement extension methods for some type. For example I have this class for ObservableCollection:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Collections.ObjectModel;
namespace MyProject.Collections.Utils
{
public static class ObservableCollection
{
public static void RemoveAll<T>(this ObservableCollection<T> collection, Func<T, bool> condition)
{
for (int i = collection.Count - 1; i >= 0; i--)
{
if (condition(collection[i]))
{
collection.RemoveAt(i);
}
}
}//RemoveAll
}
}
With this class, in my main project I can use this library with the using:
using MyProject.Collections.Utils
And when I want to use the extension methods I can do:
ObservableCollection<MyType> myOC = new ObservableCollection<MyType>();
myOC.RemoveAll(x=>x.MyProperty == "123");
So I have access to my extension method.
However, I have another class for Decimal, is this:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace MyProject.Decimal.Utils
{
public static class Decimal
{
public static decimal? Parse(this string paramString)
{
try
{
myCode
}
catch
{
throw;
}
}//Parse
}
}
But in this case, although in my main prject I import the class:
using MyProject.Decimal.Utils;
If I do this:
decimal? myDecimalParsed= Decimal.Utils.Decimal.Parse("123");
Why in this case I can't do this?:
decimal? myDecimalParsed= decimal.Parse("123");
thank so much.

Two problems:
You can't use extension methods as if they were static methods of the extended type
System.Decimal already has a Parse method, and the compiler always looks for "real" methods before extension methods.
In fact, you can write
decimal? miTiempoEstimadoParseado = decimal.Parse("123");
... but that will just call the normal method and then convert the decimal to decimal? implicitly in the normal way.
Note that you're not really using your method as an extension method at the moment anyway - to do so you'd write something like:
decimal? miTiempoEstimadoParseado = "123".Parse();
... but personally I'd view that as pretty ugly, partly as the method name doesn't indicate the target type at all, and partly because by convention Parse methods throw an exception instead of returning a null value on failure. You probably want to come up with a different name.

Visual Studio unable to resolve class name unless using nested using block

I have a class that's name is the same as the namespace is is contained within:
Class File ReadModel.cs
namespace App.Core.ReadModel
{
public class ReadModel
{
}
}
Class File MyClass.cs
using App.Core.ReadModel; // this does not work
namespace Something
{
// using App.Core.ReadModel (Works if I un-comment)
public class MyClass
{
public void test()
{
var x = new ReadModel();
}
}
}
When trying to instantiate the class, even when trying to add a using directive at the top, the compiler is still unable to resolve the class. HOWEVER, if I put the using statements nested within the namespace, it works fine.
Can someone pls explain why this works? This is a new feature I've just discovered.
The error is: App.Core.ReadModel is a namespace but is used like a type

The difference between
using System ;
using Foo.Bar ;
namespace My.Widget.Tools
{
public class MySpecialTool
{
...
}
}
and
using System ;
namespace My.Widget.Tools
{
using Foo.Bar ;
public class MySpecialTool
{
...
}
}
is that in the first case, the directive using Foo.Bar ; causes the objects in the namespace Foo.Bar to be imported into the unnamed (global) namespace for the compilation unit. In the second case, the using directive imports the objects in the namespace Foo.Bar into the namespace My.Widget.Tools.
The difference has to do with search order in resolving unqualified references.
Unqualified references are resolved by first searching within the enclosing named namespace. If the reference is not resolved, then the unnamed (global) namespace for the compilation unit is searched.
Consider the case where the above namespace Foo.Bar contains a visible class that conflicts with a class contained in the System namespace.
In the first case, where the Foo.Bar namespace has been loading into the global namespace, you'll get an error regarding an ambiguous reference if you try to reference the conflicting object: it will search the enclosing namespace first, on not finding it, it will then look into the global namespace and find multiple objects and whine.
In the second case, the enclosing namespace is searched first, on finding an object of the desired name, the unqualified reference is resolved and the compiler is happy: no conflict.
Note that you can coerce the search order to the global namespace by qualifying an object reference with the global:: prefix. You can also define your own aliases with the using directive, either for a namespace:
using io = System.IO ;
or for a type:
using IntList = System.Collections.Generic.List<int> ;
the caveat with defining an alias for the namespace is that you then have to use the alias to resolve a reference. An alias defined for a type just gives you a [perhaps] shorthand way of naming the type. Probably more useful for generics than anything else. I don't see a lot of value in doing something like:
using Row = System.Data.DataRow ;
outside of writing obfuscated C#.
See also this question: Should 'using' statements be inside or outside the namespace?
§16 of ISO/IEC 23270:2006 (Information technology -- Programming languages -- C#) will tell you far more than you ever wanted to know about namespaces and using directives.
See also this MSDN piece on namespace aliases: http://msdn.microsoft.com/en-us/library/c3ay4x3d(v=vs.80).aspx

Edit again:
Nicholas answered your revised question very nicely. Please see his answer:
Visual Studio unable to resolve class name unless using nested using block
EDIT:
Using have to be at the top of the file. Move the using above the first namespace.
Example:
namespace App.Core.ReadModel
{
public class ReadModel
{
}
}
using App.Core.ReadModel; // cannot be placed here. Must be at top of file.
namespace App
{
public class Program
{
public static Main()
{
var obj = new ReadModel();
}
}
}
Original Answer (irrelevant to question):
Option 1: Rename Namespace
namespace App.Core.IO
{
public class ReadModel
{
}
}
Option 2: Use an Alias
using MyReadModel = App.Core.ReadModel.ReadModel;
public class Program
{
public static void Main()
{
var obj = new MyReadModel();
}
}
Option 3: Qualify Type Name
public class Program
{
public static void Main()
{
var obj = new App.Core.ReadModel.ReadModel();
}
}

Using Statement with Generics: using ISet<> = System.Collections.Generic.ISet<>

Since I am using two different generic collection namespaces (System.Collections.Generic and Iesi.Collections.Generic), I have conflicts. In other parts of the project, I am using both the nunit and mstest framework, but qualify that when I call Assert I want to use the nunit version by
using Assert = NUnit.Framework.Assert;
Which works great, but I want to do the same thing with generic types. However, the following lines do not work
using ISet = System.Collections.Generic.ISet;
using ISet<> = System.Collections.Generic.ISet<>;
Does anyone know how to tell .net how to use the using statement with generics?

Unfortunately, the using directive does not do what you want. You can say:
using Frob = System.String;
and
using ListOfInts = System.Collections.Generic.List<System.Int32>;
but you cannot say
using Blob<T> = System.Collections.Generic.List<T>
or
using Blob = System.Collections.Generic.List
It's a shortcoming of the language that has never been rectified.

I think you're better off aliasing the namespaces themselves as opposed to the generic types (which I don't think is possible).
So for instance:
using S = System.Collections.Generic;
using I = Iesi.Collections.Generic;
Then for a BCL ISet<int>, for example:
S.ISet<int> integers = new S.HashSet<int>();

The only way you can alias a generic type is to specialize it as follows.
using IntSet = System.Collections.Generic.ISet<int>;
You can not alias an open generic type as you have done in your example:
using MySet = System.Collections.Generic.ISet<>;

Your alias name is the same as the class name itself, so you still have ambiguity, just as if you had a using for each namespace. Give the alias of the class a different name, i.e.:
using FirstNamespace;
using OtherObject = SecondNamespace.MyObject;
public class Foo
{
public void Bar()
{
MyObject first = new MyObject;//will be the MyObject from the first namespace
OtherObject second = new OtherObject;
}
}

In some cases you can go with inheritance:
public class MyList<T1, T2> : List<Tuple<IEnumerable<HashSet<T1>>, IComparable<T2>>> { }
public void Meth()
{
var x = new MyList<int, bool>();
}

You can alias a class doing :
using Test = NameSpace.MyClass;
Only if the class is NOT generic.

C#: property/field namespace ambiguities

I get compile error because the compiler thinks Path.Combine refers to my field, but I want it to refer to class System.IO.Path. Is there a good way to handle this other than always having to write the FQN like System.IO.Path.Combine()?
using System.IO;
class Foo
{
public string Path;
void Bar(){ Path.Combine("",""); } // compile error here
}

You can do this:
using IOPath = System.IO.Path;
Then in your code:
class Foo
{
public string Path;
void Bar(){ IOPath.Combine("",""); } // compile error here
}

Seperate your references:
this.Path = System.IO.Path.PathFunction();
I'd strongly suggest implying the System.IO namespace when using Path anywhere inside that class, because it's very difficult to tell the difference. Using the this. qualifier and the full namespace makes them distinct.