Pages

Showing posts with label GAC. Show all posts
Showing posts with label GAC. Show all posts

Tuesday, December 13, 2011

MCA-512 (UNIT V) - Dot Net Framework and C# (Assembly)


Assembly an Introduction

An assembly is a small logical collection of classes that contains the metadata of an application and components and resources that enable you to create an application. An assembly is one of the main components of the .NET framework and it is developed during the Runtime. An assembly provides the CLR with the metadata, which describes types, members, and references in your code. The runtime uses the metadata to locate and load classes, lay out instances in memory, generate native code, and enforce security.
It contains a manifest for executing a Microsoft Intermediate Language-based code (MSIL) at the CLR.Before the advent of the .NET platform, the business logic was implemented in the COM component. The main problem with COM is that it is tightly coupled with the operating system. When you deploy a COM component on a system, it copies the related .dll or .exe file to a specific location and makes an entry for the file in the registry. In COM, every component is uniquely identified in the registry through a Globally Unique Identifier (GUID).

DLL-hell Problem
COM-based systems are prone to the classic dll-hell problem. You cannot modify a component after it is deployed without affecting existing clients. COM provides a mechanism to register and access multiple versions of a component in the registry, but the operating system does not provide a mechanism to prevent an earlier version of a .dll from accidentally overwriting a newer version.

Needs for Assemblies
The assembly handles the operating system dependency and DLL-hell problems because it is a self-describing unit. You can maintain two versions of the same assembly on the same system.
COM-based systems are prone to the classic dll-hell problem. You cannot modify a component after it is deployed without affecting existing clients. COM provides a mechanism to register and access multiple versions of a component in the registry, but the operating system does not provide a mechanism to prevent an earlier version of a .dll from accidentally overwriting a newer version.The assembly handles the operating system dependency and DLL-hell problems because it is a self-describing unit. You can maintain two versions of the same assembly on the same system.
When Microsoft developed the .NET platform, the operating system dependency and the dll-hell problems were a major focus and it wanted to remove the coupling between the platform and the registry. The metadata of an application resides in the application itself and provides multiple versions of applications on the same system because each version maintains its own metadata.

 Assembly Advantages
- Easy Deployment: Allows you to deploy a .NET component on a client computer with a simple Xcopy command.
- Side-by-side Execution: Allows other applications to use assemblies in addition to the primary application.
- Operating System Independence: Allow you to port assemblies to any operating system that supports a .NET common runtime environment.

Structure of an Assembly
A .NET assembly consists of assembly metadata and the assembly manifest contains the type information, resources, and the MSIL code to implement type metadata in an assembly. The manifest is an important component of an assembly. The assembly manifest contains the following:
- Identity Information: Identifies the assembly uniquely by the combination of four properties:
assembly name, assembly version, culture, and strong name.
- File List Information: Includes types and declarations defined in another file. Every assembly is made up of one or more files. The manifest maintains a list of files that make up the assembly. The manifest maps the file containing the types and declarations to the file containing the declaration and implementation of an application.
- Identity Information:  Identifies the assembly uniquely by the combination of four properties:
assembly name, assembly version, culture, and strong name.
- File List Information: Includes types and declarations defined in another file. Every assembly is made up of one or more files. The manifest maintains a list of files that make up the assembly. The manifest maps the file containing the types and declarations to the file containing the declaration and implementation of an application.
- Referenced Assembly Information: Includes the information of references to other assemblies. In application development, you can develop various components that are spread across various assemblies.
- Exported Type References: Includes information about the functions and types that are exported and available to other assemblies. The components of other assemblies may refer to the methods and properties in the current assembly.
- Type Metadata: Provides the description of each class type. The manifest includes the name of each class type exported from the assembly and the information about the file containing its metadata.
- Resources: Includes resources such as bitmaps that you can integrate into a manifest. The assembly's resource section contains information on the resources the application uses.
- MSIL Code: Contains the compiled code in the MSIL format. The manifest is the system information about the assembly. The .NET platform compiles code written in a CLS-compliant language to an Intermediate Language (IL). The MSIL compiler compiles the source code to an IL form. When the .Net-based code is executed, the just-in-time compiler of the .NET runtime compiles the IL code to the executable form. The runtime loads the compiled code segment in memory and executes it. As a result, the system stores the complete compiled code as part of the assembly in IL format and recompiles and executes it. This happens only once between the loading and unloading of the .NET runtime.

Types of Assemblies
There are two types of assemblies, single-file and multi-file assemblies. In the .NET platform there is no difference between the two. Based on the structure, constraints, and requirements of the development team, you can choose either type of assembly.

                Single-File Assembly
                Multi-File Assembly
Single-File Assembly-A single-file assembly stores the manifest, type metadata, IL, and resources in a single file. You can use this approach for simple applications when you need to develop an assembly for a small-scale deployment.
Multi-File Assembly: For example, you can have different modules related to the system administration functionality, developed over a period of time. Using the multi-file assembly feature of .NET, you can group all administration functionality modules into an assembly to facilitate component versioning and maintenance.


Scope of Assemblies
Assemblies can either contain a private or a public scope, based on the level of access required by the clients who access it. The manifest contains information regarding the scope of an assembly.
               
                          Private Assembly
                          Shared Assembly
Private Assembly- Assemblies are private in scope if only one application can access them. Private assemblies are only available to clients in the same directory structure as the assembly. As a result, the .NET assembly resides in the same directory structure as the client executable. You can use a private assembly when it is specific to a client application and no other client application refers to it.
Shared Assembly-When an assembly such as a system assembly contains features shared by various applications, standard deployment techniques discourage the use of private assemblies. As a result, you need to maintain a copy of the assembly for each client application. You can also register the assembly in the Global Assembly Cache (GAC), so that all client applications refer to one copy of the assembly. This type of assembly is called a shared assembly. The side-by-side execution feature of the .NET platform enables you to register multiple versions of the same assembly in GAC.

Global Assembly Cache(GAC): GAC is a repository of assemblies used by multiple applications on a system. When you install the .NET runtime on a system, it creates a cache, which can be used to store assemblies.
 Advantages
The advantages of storing an assembly as a shared assembly in GAC are:
- Multiple Applications: Allows you to access an assembly from one location, GAC. If multiple applications use the same assembly, instead of keeping a copy of the assembly in each application folder, you can store a shared assembly in GAC.
- Automatic Search Location: Enables the client application to easily access an assembly stored in GAC. When the runtime searches for an assembly, GAC is the default location it searches.
Security: Ensures that only the system administrator can modify permissions of the folder. The GAC is always installed in the system folder. It inherits the permissions and Access Control Lists (ACLs) present in the system folder. As a result, you can protect GAC from unauthorized modifications.
- Side-by-side Versioning: Enables you to maintain multiple versions of the same application on a system. Private assemblies enable you to maintain a copy of the assembly in every client application folder. When a new version of an assembly is released, instead of updating the assemblies in all client applications, you can maintain multiple versions of the assembly in a central location, GAC. Client applications can refer to various versions of assemblies in GAC.

Disadvantage of Storing an Assembly in GAC
In a private assembly, you can use a simple Xcopy operation for deployment, which you cannot use for GAC-based assemblies. The assembly has to be physically registered in the GAC of client computers. For example, assemblies stored in the GAC should have the same assembly name and file name, which means that you should save assembly name abc as abc.exe or abc.dll.




Followers