he third release of the .NET Framework (version 2.0) introduces many changes and innovations not just in the application frameworks, but also in the essential mechanics of assemblies themselves.
Microsoft strove to improve on a few limitations of the original assemblies model, as well as provide new features and capabilities in assemblies and in the tools used to build and manage them, predominantly Visual Studio 2005. These include application assembly reference, reference aliasing, friend assembly, better strong name protection, specific versioning, and targeting specific CPU architectures, and more. This article describes each such new feature, and when applicable, recommends best practices and guidelines.
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 EXE assemblies, and the lines between them are very much blurred.
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:
|Visual Studio 2005 allows developers to add a reference to both library and application assemblies.|
- You can directly launch only 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 available only 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.