All details about assembly

Assembly : =>

ð  Assemblies are the building blocks of .NET Framework applications; they create the fundamental unit of deployment, version control, reuse, activation scoping, and security permissions.

ð  An assembly is a collection of types and resources that are built to work together and make a logical unit of functionality.

ð  They are self-describing components that have no dependencies on registry entries.

ð  Assemblies enable zero-impact application installation. They also simplify uninstalling and replicating applications.

ð  Assemblies can be static or dynamic .

ð  Static assemblies can include .NET Framework types (interfaces and classes), as well as resources for the assembly (bitmaps, JPEG files, resource files, and so on). Static assemblies are stored on disk in portable executable (PE) files.

ð  You can also use the .NET Framework to create dynamic assemblies, which are run directly from memory and are not saved to disk before execution. You can save dynamic assemblies to disk after they have executed.

ð  Assemblies are designed to simplify application deployment and to solve versioning problems that can occur with component-based applications.

ð  Many deployment problems have been solved by the use of assemblies in the .NET Framework. Because they are self-describing components that have no dependencies on registry entries, assemblies enable zero-impact application installation. They also simplify uninstalling and replicating applications.

ð   

ð  Note:- It contains code that the common language runtime executes. Microsoft intermediate language (MSIL) code in a portable executable (PE) file will not be executed if it does not have an associated assembly manifest.

To solve versioning problems, as well as the remaining problems that lead to DLL conflicts, the runtime uses assemblies to do the following:

ð  Enable developers to specify version rules between different software components.

ð  Provide the infrastructure to enforce versioning rules.

ð  Provide the infrastructure to allow multiple versions of a component to be run simultaneously (called side-by-side execution).

In general, a static assembly can consist of four elements:

• The assembly manifest, which contains assembly metadata.
• Type metadata.
• Microsoft intermediate language (MSIL) code that implements the types.
• A set of resources.

Only the assembly manifest is required, but either types or resources are needed to give the assembly any meaningful functionality.

There are several ways to group these elements in an assembly. You can group all elements in a single physical file, which is shown in the following illustration.

Single-file assembly

ð 

Assembly contains a collection of data that describes how the elements in the assembly relate to each other. The assembly manifest contains this assembly metadata. An assembly manifest contains all the metadata needed to specify the assembly's version requirements and security identity having assembly name, version number, culture and strong name, and all metadata needed to define the scope of the assembly and resolve references to resources and classes. The assembly manifest can be stored in either a PE file (an .exe or .dll) with Microsoft intermediate language (MSIL) code or in a standalone PE file that contains only assembly manifest information.

Global Assembly Cache:--

Each computer where the common language runtime is installed has a machine-wide code cache called the global assembly cache. The global assembly cache stores assemblies specifically designated to be shared by several applications on the computer.

Strong Name:è 

A strong name consists of the assembly's identity having its simple text name, version number, and culture information , as well as public key and a digital signature.

Strong name provides uniqueness to assembly by relying on unique key pairs. It indicates that an assembly generated with one private key has a different name than an assembly generated with another private key.

When you reference a strong-named assembly, you expect to get certain benefits, such as versioning and naming protection. If the strong-named assembly then references an assembly with a simple name, which does not have these benefits, you lose the benefits you would derive from using a strong-named assembly and revert to DLL conflicts. Therefore, strong-named assemblies can only reference other strong-named assemblies.

 Satellite Assemblyà 

• A satellite assembly consists of resources specific to a given language. Using satellite assemblies, we can place resources for different languages in different assemblies and the correct assembly is loaded into memory only if the user elects to view the application in that language.

       ·   A single satellite assembly must include all the resources for a particular culture.

       ·   The satellite assembly must have the same name as the application, and must use the file name extension ".resources.dll". For example, if an application is named Example.exe, the name of each satellite assembly should be Example.resources.dll.

 Note that the satellite assembly name does not indicate the culture of its resource files. However, the satellite assembly appears in a directory that does specify the culture.

This means that you develop your application in a default language and add flexibility to react with change in the locale. Say, for example, you developed your application in an en-US locale. Now, your application has multilingual support. When you deploy your code in, say, India, you want to show labels, messages shown in the national language which is other than English.

Satellite assemblies give this flexibility. You create any simple text file with translated strings, create resources, and put them into the bin\debug folder. That's it. The next time, your code will read the CurrentCulture property of the current thread and accordingly load the appropriate resource.

This is called the hub and spoke model. It requires that you place resources in specific locations so that they can be located and used easily. If you do not compile and name resources as expected, or if you do not place them in the correct locations, the common language runtime will not be able to locate them. As a result, the runtime uses the default resource set.

Creating a Satellite Assembly

1. Create a folder with a specific culture name (for example, en-US) in the application's bin\debug folder.
2. Create a .resx file in that folder. Place all translated strings into it.
3. Create a .resources file by using the following command from the .NET command prompt. (localizationsample is the name of the application namespace. If your application uses a nested namespace structure like MyApp.YourApp.MyName.YourName as the type of namespace, just use the uppermost namespace for creating resources files—MyApp.)

1.  resgen Strings.en-US.resx LocalizationSample.

1.    Strings.en-US.resources

3.  al /embed:LocalizationSample.Strings.en-US.resources

1.    /out:LocalizationSample.resources.dll /c:en-US

The above step will create two files, LocalizationSample.Strings.en-US.resources and LocalizationSample.resources.dll. Here, LocalizationSample is the name space of the application.

1. In the code, find the user's language; for example, en-US. This is culture specific.
2. Give the assembly name as the name of .resx file. In this case, it is Strings.

Using a Satellite Assembly

Follow these steps:

1.  Thread.CurrentThread.CurrentCulture =

1.    CultureInfo.CreateSpecificCulture(specCult);

3.  Thread.CurrentThread.CurrentUICulture =

1.    new CultureInfo(specCult);

5.  ResourceManager resMgr =

1.    new ResourceManager(typeof(Form1).Namespace + "." +
2.                        asmName, this.GetType().Assembly);

8.  btnTest.Text = resMgr.GetString("Jayant");

That's it. See how simple is it to create a satellite assembly and use it in your code.

Here's how to use a satellite assembly if your assembly is a strong named assembly. When you create an assembly with a string name, all the assemblies it refers to must have a strong name. This is true with a satellite assembly also. Here are the steps to create a strong named satellite assembly.

String Naming a Satellite Assembly

1.  al /embed:ExploreDotNet2005.Strings.en-US.resources

1.    /out:ExploreDotNet2005.resources.dll /c:en-US
2.    /template:../ExploreDotNet2005.exe /keyfile:../../..
3.    /KeyPair.snk

Remember that /template is very important because it inherits the parent assembly manifest, and the strong name key pair must be the same as that for the running assembly. I've tried using different strong names for satellite assembly and executing the assembly. but it throws an exception.

Side-by-side execution is the ability to store and execute multiple versions of an application or component on the same computer. This means that you can have multiple versions of the runtime, and multiple versions of applications and components that use a version of the runtime, on the same computer at the same time. Side-by-side execution gives you more control over what versions of a component an application binds to, and more control over what version of the runtime an application uses.

Assembly Version Number

Each assembly has a version number as part of its identity. As such, two assemblies that differ by version number are considered by the runtime to be completely different assemblies. This version number is physically represented as a four-part string with the following format:

major version>.minor version>.build number>.revision>

For example, version 1.5.1254.0 indicates 1 as the major version, 5 as the minor version, 1254 as the build number, and 0 as the revision number.

The version number is stored in the assembly manifest along with other identity information, including the assembly name and public key, as well as information on relationships and identities of other assemblies connected with the application.

Delay Signing:==

Delay signing is a process of generating partial signature during development with access only to the public key. The private key can be stored securely and used to apply the final strong name signature just before shipping the project.

Scenerio:-

Delayed Signing = It is possible that you come to a situation where you have to give your assembly for further modification to an external person/developer, but you cannot give him the private key of the assembly, then how could he work? This problem has been solved by the Delayed Signing technique.

In this, we can skip the signing of the assembly with the private key and turn off the assembly verification. So now, the Assembly signs with only Public key. Now you can give the developer the assembly and public key only, there is no need of private key. This can be done like this, we have already created "StrongFile" assembly.

Process:-

With the help of sn.exe, we can extract the public key in the file:

Collapse | Copy Code

Syntax : sn -p [infile] [outfile] 

Extract the public key in key pair in [infile] and export it to the [outfile].

Collapse | Copy Code

sn /p FileKey.snk PublicKey.snk   

This will create the file "PublicKey.snk" which contains the public key of our assembly StrongFile.

Now it's time to edit the AssemblyInfo.cs like this:

Build Assembly StrongFile again.

Note = If you delayed signing of assembly by Properties Signing tab, then you need not edit AssemblyInfo.cs.

Now we have to turn off the verification process in this way:

sn /Vr StrongFile.dll

Then, you will get the following message:

Now you can send the developer your assembly with the public key file only, i.e., StrongFile.dll assembly with ThePublicKey.snk only. After he is done with his work, you can reassign the assembly with a private key like this:

sn /R StrongFile.dll FileKey.snk