What's New in .NET 2.0 for Assemblies and Versioning?
Referencing Application Assembly Visual Studio 2003 only allows developers to add a reference to a library assembly. The client of a component in a class library assembly (.DLL) could reside in the same assembly as the component, in a separate class library, or in a separate application assembly (.EXE). The client of a component in an application assembly could only reside in the same application assembly as the component. This was analogous to the use of classic Windows DLLs, though there was nothing specific in .NET itself that precluded using components in an application assembly by other assemblies. Visual Studio 2005 allows developers to add a reference to both library and application assemblies. This enables you to treat an EXE application assembly just as if it were a DLL library assembly. This new capability is demonstrated in Figure 1. The client in the assembly named EXE 1 can consume Class D, which resides in the application assembly named EXE 2. 
Figure 1: Consuming components in application or class library assemblies. You can even add application assemblies to the GAC. There is no longer the strict distinction (inherited by convention not by capability from Windows) between DLLs and EXEs assemblies, and the lines between them are very much blurred. | " |
Visual Studio 2005 allows developers to add a reference to both library and application assemblies.
| " |
Anything you can do with a DLL library assembly, you can do with an EXE application assembly. For example, nothing prevents you from having a logical application comprised of one EXE application assembly with the user interface in it, and several other EXE application assemblies referenced by the user interface assembly, all loaded in the same process (as well as the same app domain). However, the other way around is not true there are a few things you can only do with an EXE application assembly: - You can only directly launch an application assembly (be it a Windows or a Console application). You cannot launch a class library.
- Only an application assembly used to launch the process has a say on the CLR version used.
- Visual Studio 2005 partial trust debugging is only available for application assemblies.
- ClickOnce publishing and deployment is only available for an application assembly.
That said, I still recommend that you put components in library assemblies whenever possible. This will enable the components to be used by different applications with different CLR versioning policies. It will also enable bundling the components with different ClickOnce applications and deploy the components with different security and trust policies. Reference Aliasing In .NET 2.0, by default, all types are rooted in a namespace called global. For example, this class definition: class MyClass
{}
is identical to this one: namespace global
{
class MyClass
{}
}
You don't need to explicitly use the global namespace since it is always implied by default. The global namespace is instrumental in resolving type name conflicts, especially when multiple assemblies are involved. When you add an assembly reference, it is possible to create a conflict with another type already defined by your application in another assembly it references. For example, consider the MyApplication.exe and MyLibrary.dll assemblies, which both define the class MyClass in the namespace MyNamespace. //In MyApplication.exe
namespace MyNamespace
{
public class MyClass
{...}
}
//In MyLibrary.dll
namespace MyNamespace
{
public class MyClass
{...}
}
Each definition of MyClass is completely distinct, providing different methods and behaviors. If you add a reference to MyLibrary.dll from within MyApplication.exe, when you try to use the type MyClass like so:. using MyNamespace;
MyClass obj = new MyClass();
The compiler will issue an error because it does not know how to resolve it that is, it doesn't know which definition of MyClass to reference. C# 2.0 allows you to resolve type name conflicts by aliasing the assembly reference. By default, all namespaces are rooted in the global namespace. When aliasing an assembly, the namespaces used in that assembly will be resolved under the alias, not globally. To alias an assembly, first add a reference to it in Visual Studio 2005. Next, expand the Reference folder in the Solution Explorer, and display the properties of the referenced assembly (Figure 2). 
Figure 2: Aliasing an assembly reference.If you added the reference by browsing to the assembly, the Aliases property will be set explicitly to global. If you added the reference by selecting the assembly from the Projects tab, the Aliases value will be empty (but implicitly global). You can specify multiple aliases, but for addressing most conflicts a single alias will do (unless you also have conflicts with other aliases). | " |
C# 2.0 allows you to resolve type name conflicts by aliasing the assembly reference.
| " |
Next, add as the first line of the file the extern alias directive, instructing the compiler to include the types from the alias in the search path. extern alias MyLibraryAlias;
You can now refer to the class MyClass from MyLibrary.dll. MyLibraryAlias::MyNamespace.MyClass obj;
obj = new MyLibraryAlias::MyNamespace.MyClass();
Note that the extern alias directive must appear before any using directives, and that all types in the MyLibrary.dll can only be referred to via the alias, because these types are not imported to the global scope. Using aliases and fully qualified namespaces may result in exceedingly long lines. As shorthand, you can also alias the fully qualified name. using MyLibrary = MyLibraryAlias::MyNamespace;
MyLibrary.MyClass obj;
obj = new MyLibrary.MyClass();
|