Locating Assemblies for an MSI Package

While packaging a .NET application, Identifying where the assemblies reside will purely depend on the usage of an assembly. This article will be useful in identifying where an assembly should reside. Further, it will give a brief understanding of assembly types and CLR.

An assembly can usually exist or reside in these locations.

Private Folder ("C:\Program Files\ABC\")
WinSxS ("C:\Winnt\WinSxS")
GAC ("C:\Winnt\assembly")

Private assemblies and shared assemblies

A private assembly is used only by a single application, and is stored in that application's install directory (or a subdirectory therein). A shared assembly is one that can be referenced by more than one application. In order to share an assembly, the assembly must be explicitly built for this purpose by giving it a cryptographically strong name (referred to as a strong name). By contrast, a private assembly name need only be unique within the application that uses it.

By making a distinction between private and shared assemblies, Microsoft introduces the notion of sharing as an explicit decision. Simply by deploying private assemblies to an application directory, one can guarantee that that application will run only with the bits it was built and deployed with. References to private assemblies will only be resolved locally to the private application directory.

There are several reasons one may elect to build and use shared assemblies, such as the ability to express version policy. The fact that shared assemblies have a cryptographically strong name means that only the author of the assembly has the key to produce a new version of that assembly. Thus, if one makes a policy statement that says one want to accept a new version of an assembly, one can have some confidence that version updates will be controlled and verified by the author. Otherwise, one doesn’t have to accept them.

For locally installed applications, a shared assembly is typically explicitly installed into the global assembly cache (a local cache of assemblies maintained by the .NET Framework). Key to the version management features of the .NET Framework is that downloaded code does not affect the execution of locally installed applications. Downloaded code is put in a special download cache and is not globally available on the machine even if some of the downloaded components are built as shared assemblies.

Common Language Runtime(CLR)

The common language runtime is the engine of .NET and the common runtime of all managed languages. In addition, as the final layer resting atop of the operating environment, the CLR provides the first level of abstraction. Since assemblies run within the context of the common language runtime, they are independent of the underlying operating environment and hardware. Assemblies or managed code are portable to any environment offering a .NET compliant common language runtime, as defined by the Common Language Infrastructure (CLI).

Click to view.

Managed code is managed by the common language runtime. CLR manages security, code verification, type verification, exception handling, garbage collection, a common runtime, and other important elements of program execution.

Intermediate Language (IL) sits in the middle of a development scheme. A developer works in one of the supported languages generating code. To run the code, this high-level language is compiled. Normally when a language is compiled, the output of the compiler is a program that can be directly run. With a managed code system, the compiler produces IL code that is turned into instructions that are specific to the machine on which the IL code is loaded by the Just-In-Time (JIT) compiler. This phenomenon is explained in the above figure.

CLR provides a number of services, including the following:

• Code management (loading and execution)
• Application memory isolation
• Verification of type safety
• Conversion of IL to native code
• Access to metadata (enhanced type information)
• Managing memory for managed objects
• Enforcement of code access security
• Exception handling, including cross-language exceptions
• Interoperation between managed code, COM objects, and pre-existing DLLs (unmanaged code and data)
• Automation of object layout
• Support for developer services

Reference:

MSDN and few other blogs on assemblies.