Develop Reference

What C# compiles when using namespaces

We have two applications that each compile their own code with some of the code being shared (mainly data related). It felt natural to split this design up into three namespaces and try to enforce that namespace Foo never imports namespace Bar but either can import namespace Shared.
I hope Venn diagrams are appreciated as a visualization:
However one of the classes between Foo and Bar slipped through the cracks and someone referenced a class from Bar inside Foo despite the enforcement.
And that got me wondering if how the C# compiler actually deals with this? The way I see it, one of two things could happen.
The entire namespace gets compiled into Foo. Leaving the diagram to look like this:
Or the compiler is smart enough just to extract the necesarry class. Making the diagram look like this:
I can't seem to find any documentation on how usings and namespaces compile. It seems like namespaces are just to organise code for developers, not compilers. Yet they provide scope... So I guess #2 applies then? How to even test this?

There is no correspondence between namespaces and assemblies: one assembly may contain many namespaces, and one namespace may span many assemblies.
The compiled IL code in an assembly refers to types by their fully qualified names: Foo.SomeClass instead of SomeClass, Bar.OtherClass instead of OtherClass, and so on. The compiler's job is to figure out which fully qualified type name you really mean when you write the shortened form SomeClass -- because you could have defined a class called SomeClass in the namespaces Foo, Bar, or even System!
When you write:
namespace Foo
{
public class SomeClass
{
}
}
You are defining a type with a fully qualified name Foo.SomeClass.
When you write:
using Foo;
...
SomeClass instance = new SomeClass();
The compiler treats this the same as:
Foo.SomeClass instance = new Foo.SomeClass();
Namespaces are just a construct of convenience for organizing these fully qualified names. When you say using Foo;, you are just telling the compiler to search for fully qualified names that start with Foo. whenever you type SomeClass. There is nothing being "imported" when you write using Foo;, it just provides a convenient alternative to writing Foo.SomeClass everywhere; nor does any "code" (in the sense of IL instructions being emitted) get generated by your usings or your namespaces. All it does is tell the compiler to put Foo.SomeClass into the IL whenever you write SomeClass.
The above is a simplification of a more nuanced set of rules defined in the spec for resolving short-form type names; you can read this for more details: here and here
The level at which you'd want to enforce the dependencies in your diagrams would be at the assembly reference level: if the Foo project never references the Bar assembly or vice versa, the code would not even compile if you tried to reference a type in one assembly from the other. The namespaces don't really have much to do with that at all, because again, nothing stops you from defining types in the Foo namespace but in the Bar assembly.

C# Project & Namespaces Question

I am creating a little Math library for myself contained within a single project and am running into some issues with namespaces. I have the project MyMathLib and the top level namespace:
namespace MyMathLib
{ ... }
and in a separate file...
namespace MyMathLib.Addition
{ ... }
and...
namespace MyMathLib.Subtraction
{ ... }
In the MyMathLib.Subtraction namespace I have a method that needs to use a static method SomeClass.Work() defined in MyMathLib.Addition so I included using MyMathLib.Addition at the beginning of the Subtraction file. But when I try to use the method it would like me to first qualify it with Addition.SomeClass.Work() and I want to be able to just type SomeClass.Work(). What am I doing wrong?
Thanks!
EDIT
Thanks for the suggestions! In each file, I actually named the class after the namespace (i.e. in the namespace MyMathLib.Addition is a static class Addition and in MyMathLib.Subtraction there is a static class Subtraction). Apparently this is what caused the issue (looking back, I should have stated this instead of using SomeClass). If I change the namespace to MyMathLib.MyAddition while keeping the static class as Addition, the using MyMathLib.MyAddition works as I want; that is, I can now just type Addition.Work() in my static Subtraction class. I've seen classes named the same as it's containing namespace before, could someone maybe explain why this is causing an issue? Shouldn't the compiler be able to determine whether I want to use the namespace or the class from the context of the code?

I'm guessing that you either have two classes called SomeClass that are both in namespaces you reference, or you have a variable or property named SomeClass. Either of these situations would make it impossible for the compiler to know that you're trying to call the static MyMathLib.Addition.SomeClass.Work() method, but the specific solution the compiler is suggesting makes it seem more likely to be the former.
Update
Seeing your edit, that makes sense. If you were using these in a namespace outside of MyMathLib, then you would still be able to avoid this namespace conflict. However, because you are inside the MyMathLib.Subtraction namespace, the compiler will implicitly consider any portion of the namespace "above" you to take precedence over class names. In this case, when you say "Addition", the compiler will look for the following items to resolve the name:
A class explicitly identified by a using ... = ... directive.
MyMathLib.Subtraction.Addition namespace.
MyMathLib.Addition namespace.
Addition namespace.
Any classes in the namespaces identified by using statements.
In this case, you're hitting #3 before #4, so you should be able to work around it either by renaming the class or namespace, or by using Yahia's suggestion (#1):
using Addition = MyMathLib.Addition.Addition;
Update 2
After looking at the article you linked to, it sounds like the explicit using statement still won't work. I guess item #1 actually gets evaluated down around item #4 instead. Bummer. You can use an alias to give the class a different name locally:
using Add = MyMathLib.Addition.Addition;
...
var add = new Add();
But the best solution is still probably just to avoid the namespace collision entirely by changing your namespace or class name.

try putting additionally the floowing line into your substraction source
using SomeClass = Addition.SomeClass;
http://msdn.microsoft.com/en-us/library/dfb3cx8s.aspx
http://www.blackwasp.co.uk/NamespaceAliasQualifier.aspx

Sounds like you're in the Subtraction namespace...add this to the top, inside the namespace declaration:
using Addition;
That should do the trick.

How to assign same class object declared in 2 different namespaces

I have a webservice project with a class (let's refer to it as webservice.classA).
I have another class project producing a dll which references that class in its own namespace and instantiates an instance of it (lets call the dlls namespace dllnamespace).
In another project I want to access the member in the dll
e.g.
using webservice;
namespace other_project
{
class B
{
classA copy = null;
//....
dllnamespace.dostuff(); // amongst other things instantiates a classA object
//....
copy = dllnamespace.getclassA(); // method to return classA member
The compiler error I get is cannot convert type from dllnamespace.webservice.classA to other_project.webservice.classA
I guess I have a fundamental design flaw but I figure there must be (?) a way to declare/use "webservice.classA" in more than one namespace.

You have a name clash. The supported way of avoiding this (short of not naming your classes the same), is to define a using alias for one of the classes:
using webservice.classA = myWebserviceClassA;

You are right...the design flaw does exist in terms of naming.
Let us assume:
you have a class named
MyClass
the class exists both in namespace- abc.xyz.qwe.tyu.MyClass
and in namespace - sed.qwe.dfg.ert.MyClass
The workaround is -
using NS1 = abc.xyz.qwe.tyu.MyClass;
using NS2 = sed.qwe.dfg.ert.MyClass;
This way you avoid the clash.
Also, helpful to use if you have very long namespaces.
FURTHER REFERENCE : (From MSDN article on using Directive )
The scope of a using directive is
limited to the file in which it
appears.
Create a using alias to make it easier to qualify an identifier to a
namespace or type.
Create a using directive to use the types in a namespace without having to specify the namespace. A using directive does not give you access to any namespaces that are nested in the namespace you specify.

Change the copy definition line to:
dllnamespace.webservice.classA copy = null;

That's just the problem - you cannot have a class in more than one namespace. This is what namespaces were designed for - to prevent classes with the same name written by different people from aliasing. You'll need to decide for one of your namespaces to own that class and in the other one to import it. Alternatively if the dll and the web service are part of the same distributed app then they should use the same namespace.

The C# namespace and class/sub-class naming conventions when the top namespace contains the base class and inner namespaces contain sub-classes

I'm trying to design a class library for a particular engineering application and I'm trying to ensure that my class & namespace naming conventions make sense.
I have the following situation:
namespace Vehicle{
class Wheel{...} //base class for Wheel objects
class Engine{...} //base class for Engine objects
...
namespace Truck{
class Wheel: Vehicle.Wheel{...} //Truck specific Wheel object
class Engine: Vehicle.Engine{...} //Truck specific Engine object
...
}
namespace Car{
class Wheel: Vehicle.Wheel{...} //Car specific Wheel object
class Engine: Vehicle.Engine{...} //Car specific Engine object
...
}
...
}
The code gets used in ways that all of these classes will need to be referenced from within the same scope. The following situation would be likely:
...
Vehicle.Wheel.DoSomething();
Vehicle.Truck.Wheel.DoSomething();
Vehicle.Car.Wheel.DoSomething();
...
Under these circumstances, am I better off giving the classes more specific names
namespace Car{
class CarWheel: Vehicle.Wheel{...} //Car specific Wheel object
...
}
or leave the naming as shown in the first example and rely on the information that is encoded in the namespace for clarity? Under the latter approach, I assume I would want to utilize alaising for clarity in the code that makes use of this library, corret?
It seems redundent to have:
Vehicle.Car.CarWheel
or
Vehicle.Truck.TruckEngine
but I also want to have very descriptive and specific class names.
Philosophically, what I'm asking is whether or not to include the namespace as a part of the class name when considering if a class name is descriptive enough.

Typically namespaces are pluralized, so as not to collide with class names (e.g. it is likely you would want classes named Vehicle and Car) so I'd be inclined to use namespaces as follows:
namespace Vehicles;
namespace Vehicles.Cars;
namespace Vehicles.Trucks;
As for the names of classes, it would be typical to prefix the class name with the specialization, especially if they are likely to be used together, so you'd end up with something like:
class CarWheel : Wheel
class TruckWheel : Wheel
You can see this type of 'redundancy' everywhere in the .NET Framework, for example in the System.Xml namespace virtually all classes are prefixed with Xml, or in the System.Data.SqlClient namespace most classes are prefixed with Sql. It means that you can import namespaces with the using directive and then not have to fully-qualify class names throughout your code, e.g. which of the following is more readable?
Vehicles.Cars.Wheel wheel = new Vehicles.Cars.Wheel();
or
CarWheel wheel = new CarWheel();
It's obvious what both are doing, but the second is considerably shorter.
Note that if you do include the specialization in the name, then you may find that you don't need all the nested namespaces (.Cars, .Trucks, etc.) which can become painful if they are usually used together, and so every file using them would have to import all the namespaces, e.g.
using Vehicles;
using Vehicles.Cars;
using Vehicles.Trucks;
using Vehicles.SomethingElse;
using Vehicles.YetAnotherThing;
If you find this same stack of using directives is at the top of each file, then collapse the classes down into a single namespace. You typically include all related functionality that is expected to be used together in a single namespace, and only use nested ones for functionality that extends the base namespace but is less frequently used.

I would try to avoid reusing names across different namespaces, particularly if a client may want to use both in the same program.
Do you really need a namespace for Car, Truck etc? All these namespaces sound more like they ought to be classes than namespacese. Perhaps in your real situation it makes more sense though...

can I expose a class from another .net namespace as a class in my namespace?

Can I expose a class from another .net namespace as a class in my namespace? I use a class - antlr.collections.AST - as the return type for a function belonging to a class in my namespace; as a result, the user has to have
using antlr.collections;
using myNamespace;
at the top of their files in order to use my function. Can I make myNamespace.AST an alias for antlr.collections.AST, such that the user only has to have
using myNamespace;
at the top of their files?

Bear in mind that the consumers of your code won't actually need to have using statements. Those are there to make their lives easier, so they don't have to type antlr.collections.Foo and antlr.collections.Bar all over their source.
The bigger "impact" (if indeed there really is a severe one) is that the consumer of your code will need a hard reference to the assembly where antlr.collections is defined.
However, if that's documented up front, I honestly don't see it being that big of a problem. It's no different than the consumer of a SubSonic-generated DAL needing references both to the generated DAL assembly and the original SubSonic assembly. (And, quite possibly, using statements as well.)
Dependencies are what they are. There's a reason classes are broken into namespaces -- primarily for organization and to reduce naming conflicts. Not knowing what classes are in the namespace you mention, I don't know how likely such a conflict actually is in your scenario ... But attempting to move the class from one namespace to another, or to hide the fact that such is needed by deriving a blank class from it, is probably not the best idea. It won't kill the consumers of your class to have another reference and using statement.

How about deriving a class using the same name in the new namespace? I meant:
namespace MyForms {
class Class1 : Some.Other.Namespace.Class1 {
// ...
}
}

create a new class that inherits the class in your new namespace. It's not ideal, but it's useful for unit testing and the like.
You should think about why you are doing this though, classes are broken up into namespaces for a reason.

No, you can't.
The full path to and name of a class is part of its identity.

If you derive from the class and return your derived class, you'll make yourself responsible for providing all of the documentation for the return type.
I think you'll be doing the developers who use your library a disservice because they won't necessarily know that what they're really working with is a type from antir.collections (not that I even know what that is, but that's not the point). If the developer comes to StackOverflow.com searching for information on that return type, are they more likely to find information if the type is from a "common" library, or from yours?

The only solution is to hide the whole dependency to the type antlr.collections.AST.
You can use an Adapter fot that purpose.