Assemblies are the building blocks of .NET Framework applications; they form 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 form a logical unit of functionality. An assembly provides the common language runtime with the information it needs to be aware of type implementations. To the runtime, a type does not exist outside the context of an assembly.
Assemblies are a fundamental part of programming with the .NET Framework. An assembly performs the following functions:
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. Note that each assembly can have only one entry point (that is, DllMain, WinMain, or Main).
It forms a security boundary. An assembly is the unit at which permissions are requested and granted.
It forms a type boundary. Every type's identity includes the name of the assembly in which it resides. A type called MyType loaded in the scope of one assembly is not the same as a type called MyType loaded in the scope of another assembly.
It forms a reference scope boundary. The assembly's manifest contains assembly metadata that is used for resolving types and satisfying resource requests. It specifies the types and resources that are exposed outside the assembly. The manifest also enumerates other assemblies on which it depends.
It forms a version boundary. The assembly is the smallest versionable unit in the common language runtime; all types and resources in the same assembly are versioned as a unit. The assembly's manifest describes the version dependencies you specify for any dependent assemblies.
It forms a deployment unit. When an application starts, only the assemblies that the application initially calls must be present. Other assemblies, such as localization resources or assemblies containing utility classes, can be retrieved on demand. This allows applications to be kept simple and thin when first downloaded.
It is the unit at which side-by-side execution is supported.
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 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.
There are several ways to create assemblies. You can use development tools, such as Visual Studio .NET, that you have used in the past to create .dll or .exe files. You can use tools provided in the .NET Framework SDK to create assemblies with modules created in other development environments. You can also use common language runtime APIs, such as Reflection.Emit, to create dynamic assemblies.
Contents of assembly
In general, a static assembly can consist of four elements:
How you will create this? How will you get the different language strings?
Satellite assemblies are often used to deploy language-specific resources for an application. These language-specific assemblies work in side-by-side execution because the application has a separate product ID for each language and installs satellite assemblies in a language-specific subdirectory for each language. When uninstalling, the application removes only the satellite assemblies associated with a given language and .NET Framework version. No core .NET Framework files are removed unless the last language for that .NET Framework version is being removed.
(For example, English and Japanese editions of the .NET Framework version 1.1 share the same core files. The Japanese .NET Framework version 1.1 adds satellite assemblies with localized resources in a \ja subdirectory. An application that supports the .NET Framework version 1.1, regardless of its language, always uses the same core runtime files.)
Assembly manifest
Every assembly, whether static or dynamic, 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, 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.
It contains Assembly name, Version number, Culture, Strong name information, List of all files in the assembly, Type reference information, Information on referenced assemblies.
Difference between assembly manifest & metadata
Assembly manifest - An integral part of every assembly that renders the assembly self-describing. The assembly manifest contains the assembly's metadata. The manifest establishes the assembly identity, specifies the files that make up the assembly implementation, specifies the types and resources that make up the assembly, itemizes the compile-time dependencies on other assemblies, and specifies the set of permissions required for the assembly to run properly. This information is used at run time to resolve references, enforce version binding policy, and validate the integrity of loaded assemblies. The self-describing nature of assemblies also helps makes zero-impact install and XCOPY deployment feasible.
Metadata - Information that describes every element managed by the common language runtime: an assembly, loadable file, type, method, and so on. This can include information required for debugging and garbage collection, as well as security attributes, marshaling data, extended class and member definitions, version binding, and other information required by the runtime.
Global Assembly Cache (GAC) and what is the purpose of it?
(How to make an assembly to public? Steps)
How more than one version of an assembly can keep in same place?
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. You should share assemblies by installing them into the global assembly cache only when you need to.
Steps
- Create a strong name using sn.exe tool
eg: sn -k keyPair.snk
- with in AssemblyInfo.cs add the generated file name
eg: [assembly: AssemblyKeyFile("abc.snk")]
- recompile project, then install it to GAC by either
drag & drop it to assembly folder (C:\WINDOWS\assembly OR C:\WINNT\assembly) (shfusion.dll tool)
or
gacutil -i abc.dll
How to find methods of a assembly file (not using ILDASM)- using Reflection
Click here to read more on reflection
http://dotnet-universe.blogspot.com/2011/09/reflection-in-net.html
What is a .Net Assembly
The .NET assembly is the standard for components developed with the Microsoft.NET. Dot NET assemblies may or may not be executable, i.e., they might exist as the executable (.exe) file or dynamic link library (DLL) file. All the .NET assemblies contain the definition of types, versioning information for the type, meta-data, and manifest. The designers of .NET have worked a lot on the component (assembly) resolution.
There are two kind of assemblies in .NET;
Private assemblies are simple and copied with each calling assemblies in the calling assemblies folder.
Shared assemblies (also called strong named assemblies) are copied to a single location (usually the Global assembly cache GAC). For all calling assemblies within the same application, the same copy of the shared assembly is used from its original location. Hence, shared assemblies are not copied in the private folders of each calling assembly. Each shared assembly has a four part name including its face name, version, public key token and culture information. The public key token and version information makes it almost impossible for two different assemblies with the same name or for two similar assemblies with different version to mix with each other.
An assembly can be a single file or it may consist of the multiple files. In case of multi-file, there is one master module containing the manifest while other assemblies exist as non-manifest modules. A module in .NET is a sub part of a multi-file .NET assembly. Assembly is one of the most interesting and extremely useful areas of .NET architecture along with reflections and attributes, but unfortunately very few people take interest in learning such theoretical looking topics.
I have used the Windows Installer that comes with Visual Studio 2003 to install a file both on the local file system and in the GAC. Steps to follow:
1) Create a Setup project (under Setup and Deployment Projects templates).
2) Open the File System Editor (if it is not already open) by selecting the "View -> Editor -> File System" menu item.
3) For local file system files:
a) Select a desired folder in which to install the files (such as Application Folder) and add one or more files to the folder (right-click on folder and select "Add -> File...", and then select file).
b) Configure the properties for the folder to point to the desired destination folder on the target machine.
4) For installing into the GAC:
a) Right-click in File System Editor window and select "Add Special Folder -> Global Assembly Cache Folder" menu item to add the GAC folder to the list.
b) Add one or more assemblies to the GAC folder (right-click on folder and select "Add -> File...", and then select file).
5) Build your Setup project and then run the resulting Setup.exe (or execute the resulting .msi). During installation, Installer will copy the designated files to the destination on the target machine and install designated assemblies to the GAC. During removal, the Installer will reverse the installation process.
DELAY SIGNING ASSEMBLY
When to Delay Sign Assemblies
In a workplace where many developers are working on a project, there is every possibility of private key of assembly being mishandled. Hence in a development environment, it becomes mandatory to maintain the integrity of the system during tests and build. This is where delay signing proves significant.
What is 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.
How to delay sign assemblies?
To use delay signing, follow these five steps:
Extract the public key from the key pair. We can use the tool sn.exe for this.
sn - pc keypairfilename ExtractPublicKey.pk
The generated public key (ExtractPublicKey.pk) can be used by development team to delay sign assemblies. This is a stage when .NET Framework will not allow us to load the delay-signed assemblies as they are yet not fully signed. Hence it becomes vital to configure our development machines such that it skips strong name signature verification for our key.
Use C# compiler to delay sign assembly as follows:
csc /delaysign+ /keyfile: ExtractPublicKey.pk test.cs
To configure the .NET Framework to skip strong name signature verification for the test.exe assembly on development machines:
sn - Vr test.exe
We can also configure our machine to skip all assemblies delay signed with the same key as test application. The following command will do this:
sn - T test.exe
The execution of above command will give us the public key token.
Public key token is b03f5f7f11d50a3a
Execute the following command to skip strong name verification for any assembly using the public key token generated above:
sn - Vr *,b03f5f7f11d50a3a
Please note that skipping strong name signature verification is something that should only be done on development machines. It should never be done in production environment as it opens up those machines to assembly spoofing attacks.
The fifth step is the final step taken before the deployment of the project to the production. We will use the securely saved private key to generate the final full strong name with sn.exe tool.
sn - Rc test.exe keypairfilename
This completes the process and adds the full signature to the assembly. A pointer to this step is that our delay-signed assemblies now don't need to be rebuilt. Any assemblies that had a reference to the delay-signed assembly also had access to its public key and are therefore able to create a full assembly reference, even though the assembly did not have a full signature.
Delay signing the assemblies is a easy and secure way of protecting the assemblies in the development environment. However please note that with delayed signing on, during testing environment none of the strong name signatures are verified. So there is a trade off. But I have a solution to this as well, the term is Test key signing that I'll discuss in my next article...
Read More
http://www.dotnetspider.com/resources/18272-how-create-shared-assembly.aspx
http://www.dotnetspider.com/forum/43223-how-create-Shared-Assembly.aspx
http://www.vkinfotek.com/assemblyhowto.html
http://www.c-sharpcorner.com/UploadFile/thiru_ji/1DotnetAssemblies02212007050300AM/1DotnetAssemblies.aspx
An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality. An assembly provides the common language runtime with the information it needs to be aware of type implementations. To the runtime, a type does not exist outside the context of an assembly.
Assemblies are a fundamental part of programming with the .NET Framework. An assembly performs the following functions:
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. Note that each assembly can have only one entry point (that is, DllMain, WinMain, or Main).
It forms a security boundary. An assembly is the unit at which permissions are requested and granted.
It forms a type boundary. Every type's identity includes the name of the assembly in which it resides. A type called MyType loaded in the scope of one assembly is not the same as a type called MyType loaded in the scope of another assembly.
It forms a reference scope boundary. The assembly's manifest contains assembly metadata that is used for resolving types and satisfying resource requests. It specifies the types and resources that are exposed outside the assembly. The manifest also enumerates other assemblies on which it depends.
It forms a version boundary. The assembly is the smallest versionable unit in the common language runtime; all types and resources in the same assembly are versioned as a unit. The assembly's manifest describes the version dependencies you specify for any dependent assemblies.
It forms a deployment unit. When an application starts, only the assemblies that the application initially calls must be present. Other assemblies, such as localization resources or assemblies containing utility classes, can be retrieved on demand. This allows applications to be kept simple and thin when first downloaded.
It is the unit at which side-by-side execution is supported.
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 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.
There are several ways to create assemblies. You can use development tools, such as Visual Studio .NET, that you have used in the past to create .dll or .exe files. You can use tools provided in the .NET Framework SDK to create assemblies with modules created in other development environments. You can also use common language runtime APIs, such as Reflection.Emit, to create dynamic assemblies.
Contents of assembly
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.
How you will create this? How will you get the different language strings?
Satellite assemblies are often used to deploy language-specific resources for an application. These language-specific assemblies work in side-by-side execution because the application has a separate product ID for each language and installs satellite assemblies in a language-specific subdirectory for each language. When uninstalling, the application removes only the satellite assemblies associated with a given language and .NET Framework version. No core .NET Framework files are removed unless the last language for that .NET Framework version is being removed.
(For example, English and Japanese editions of the .NET Framework version 1.1 share the same core files. The Japanese .NET Framework version 1.1 adds satellite assemblies with localized resources in a \ja subdirectory. An application that supports the .NET Framework version 1.1, regardless of its language, always uses the same core runtime files.)
Assembly manifest
Every assembly, whether static or dynamic, 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, 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.
It contains Assembly name, Version number, Culture, Strong name information, List of all files in the assembly, Type reference information, Information on referenced assemblies.
Difference between assembly manifest & metadata
Assembly manifest - An integral part of every assembly that renders the assembly self-describing. The assembly manifest contains the assembly's metadata. The manifest establishes the assembly identity, specifies the files that make up the assembly implementation, specifies the types and resources that make up the assembly, itemizes the compile-time dependencies on other assemblies, and specifies the set of permissions required for the assembly to run properly. This information is used at run time to resolve references, enforce version binding policy, and validate the integrity of loaded assemblies. The self-describing nature of assemblies also helps makes zero-impact install and XCOPY deployment feasible.
Metadata - Information that describes every element managed by the common language runtime: an assembly, loadable file, type, method, and so on. This can include information required for debugging and garbage collection, as well as security attributes, marshaling data, extended class and member definitions, version binding, and other information required by the runtime.
Global Assembly Cache (GAC) and what is the purpose of it?
(How to make an assembly to public? Steps)
How more than one version of an assembly can keep in same place?
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. You should share assemblies by installing them into the global assembly cache only when you need to.
Steps
- Create a strong name using sn.exe tool
eg: sn -k keyPair.snk
- with in AssemblyInfo.cs add the generated file name
eg: [assembly: AssemblyKeyFile("abc.snk")]
- recompile project, then install it to GAC by either
drag & drop it to assembly folder (C:\WINDOWS\assembly OR C:\WINNT\assembly) (shfusion.dll tool)
or
gacutil -i abc.dll
How to find methods of a assembly file (not using ILDASM)- using Reflection
Click here to read more on reflection
http://dotnet-universe.blogspot.com/2011/09/reflection-in-net.html
What is a .Net Assembly
The .NET assembly is the standard for components developed with the Microsoft.NET. Dot NET assemblies may or may not be executable, i.e., they might exist as the executable (.exe) file or dynamic link library (DLL) file. All the .NET assemblies contain the definition of types, versioning information for the type, meta-data, and manifest. The designers of .NET have worked a lot on the component (assembly) resolution.
There are two kind of assemblies in .NET;
- Private
- Shared
Private assemblies are simple and copied with each calling assemblies in the calling assemblies folder.
Shared assemblies (also called strong named assemblies) are copied to a single location (usually the Global assembly cache GAC). For all calling assemblies within the same application, the same copy of the shared assembly is used from its original location. Hence, shared assemblies are not copied in the private folders of each calling assembly. Each shared assembly has a four part name including its face name, version, public key token and culture information. The public key token and version information makes it almost impossible for two different assemblies with the same name or for two similar assemblies with different version to mix with each other.
An assembly can be a single file or it may consist of the multiple files. In case of multi-file, there is one master module containing the manifest while other assemblies exist as non-manifest modules. A module in .NET is a sub part of a multi-file .NET assembly. Assembly is one of the most interesting and extremely useful areas of .NET architecture along with reflections and attributes, but unfortunately very few people take interest in learning such theoretical looking topics.
I have used the Windows Installer that comes with Visual Studio 2003 to install a file both on the local file system and in the GAC. Steps to follow:
1) Create a Setup project (under Setup and Deployment Projects templates).
2) Open the File System Editor (if it is not already open) by selecting the "View -> Editor -> File System" menu item.
3) For local file system files:
a) Select a desired folder in which to install the files (such as Application Folder) and add one or more files to the folder (right-click on folder and select "Add -> File...", and then select file).
b) Configure the properties for the folder to point to the desired destination folder on the target machine.
4) For installing into the GAC:
a) Right-click in File System Editor window and select "Add Special Folder -> Global Assembly Cache Folder" menu item to add the GAC folder to the list.
b) Add one or more assemblies to the GAC folder (right-click on folder and select "Add -> File...", and then select file).
5) Build your Setup project and then run the resulting Setup.exe (or execute the resulting .msi). During installation, Installer will copy the designated files to the destination on the target machine and install designated assemblies to the GAC. During removal, the Installer will reverse the installation process.
DELAY SIGNING ASSEMBLY
When to Delay Sign Assemblies
In a workplace where many developers are working on a project, there is every possibility of private key of assembly being mishandled. Hence in a development environment, it becomes mandatory to maintain the integrity of the system during tests and build. This is where delay signing proves significant.
What is 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.
How to delay sign assemblies?
To use delay signing, follow these five steps:
Extract the public key from the key pair. We can use the tool sn.exe for this.
sn - pc keypairfilename ExtractPublicKey.pk
The generated public key (ExtractPublicKey.pk) can be used by development team to delay sign assemblies. This is a stage when .NET Framework will not allow us to load the delay-signed assemblies as they are yet not fully signed. Hence it becomes vital to configure our development machines such that it skips strong name signature verification for our key.
Use C# compiler to delay sign assembly as follows:
csc /delaysign+ /keyfile: ExtractPublicKey.pk test.cs
To configure the .NET Framework to skip strong name signature verification for the test.exe assembly on development machines:
sn - Vr test.exe
We can also configure our machine to skip all assemblies delay signed with the same key as test application. The following command will do this:
sn - T test.exe
The execution of above command will give us the public key token.
Public key token is b03f5f7f11d50a3a
Execute the following command to skip strong name verification for any assembly using the public key token generated above:
sn - Vr *,b03f5f7f11d50a3a
Please note that skipping strong name signature verification is something that should only be done on development machines. It should never be done in production environment as it opens up those machines to assembly spoofing attacks.
The fifth step is the final step taken before the deployment of the project to the production. We will use the securely saved private key to generate the final full strong name with sn.exe tool.
sn - Rc test.exe keypairfilename
This completes the process and adds the full signature to the assembly. A pointer to this step is that our delay-signed assemblies now don't need to be rebuilt. Any assemblies that had a reference to the delay-signed assembly also had access to its public key and are therefore able to create a full assembly reference, even though the assembly did not have a full signature.
Delay signing the assemblies is a easy and secure way of protecting the assemblies in the development environment. However please note that with delayed signing on, during testing environment none of the strong name signatures are verified. So there is a trade off. But I have a solution to this as well, the term is Test key signing that I'll discuss in my next article...
Read More
http://www.dotnetspider.com/resources/18272-how-create-shared-assembly.aspx
http://www.dotnetspider.com/forum/43223-how-create-Shared-Assembly.aspx
http://www.vkinfotek.com/assemblyhowto.html
http://www.c-sharpcorner.com/UploadFile/thiru_ji/1DotnetAssemblies02212007050300AM/1DotnetAssemblies.aspx
No comments:
Post a Comment