How does .NET locate the dll of the namespace I'm `using`?

Question

How does .NET locate the dll of the namespace I'm using? yeah, we do mention the path in /referene:c:\program files** but after building & deploying and when the software is installed on some user's machine. It may not be at the same path as I (developer) mentioned it would be. I mean it could be some where else right?

1. So, how does .NET find it?
2. How does .NET know at the runtime what all namespaces are there in a dll?
3. What if the user has the same dll but he renamed it? Does .net fails to load it then?

Answer 1

Assembly location rules are explained in http://msdn.microsoft.com/en-us/library/yx7xezcf.aspx

Answer 2

The names of assemblies and namespaces are unrelated concepts.

Compiled assembly reference other assemblies by containing their name.

When an assembly is loaded, its references are loaded by searching for the name as described here. The most common location for assemblies are the Global Assembly Cache of a machine, and the base directory of an application.

After loading the assembly and all its references (and the references of the references, etc) the runtime loads the required types from the assemblies.

For example, if you use the type String as in

using System;

...
String x = "Hello World";

the C# compiler looks up String and resolves it to the System.String type in the mscorlib assembly, and transforms the code to something similar to this:

[mscorlib]System.String x = "Hello World";

So when the statement is executed the runtime knows both the full name of the type System.String and the name of the assembly that contains the type.

Answer 3

Technically, there aren't any namespaces in the DLL.

On CLR level, there are no namespaces at all, only full class names. A CLR class name can consist of an arbitrarily long sequence of any Unicode characters - e.g. @#$% would be a perfectly fine class name, as far as CLR is concerned.

Now, by convention (CLS, to be specific), class names are restricted to certain Unicode characters (alphanumerics and _, and a bunch of other exotic Unicode categories - see the spec for more info) and dot, and dot is used to denote namespaces. This is purely a convention between compilers (and other tools).

So, whenever an assembly references some type for any reason, it simply uses its complete CLR name, such as System.String. But there is more - in fact, it uses a fully qualified name, which includes an assembly as well. You can see those if you look at ildasm output - they look something like [mscorlib]System.String, so the runtime knows where to look.

In other words, CLR really sees assembly mscorlib.dll having class System.String, and assembly B.exe referencing that class as [mscorlib]System.String. Your using statement doesn't generate any code in the output DLL/EXE on its own; it's there just so that you don't have to write System.String all the time.

It's compiler's job to translate your code saying String, in a scope of a using System; statement, in a project which references mscorlib.dll, to [mscorlib]System.String. It's all done at compile-time. The only thing CLR does at runtime is resolving mscorlib to locate the actual mscorlib.dll on disk (and the other answer explains how exactly that happens).

Answer 4

You can see the various probing steps in action if you run fuslogvw.exe (from the .NET SDK) and enable logging of all binds to disk. You will be able to see the various paths that .NET CLR uses to resolve assembly references. The rule of thumb though is to try the Global Assembly Cache first then check the local directory along with a bunch of other alternate paths.