Overview

• According to CLI specification, assembly is the CIL output after code’s compilation.
• Assemblies can be library assemblies (DLL – Class Libraries) or process assemblies (EXE - Executables).
  • An assembly can consist of one or more files.
  • However, there is only one version number for the entire group of files and it is placed in the main assembly manifest.
  • These files can include compiled modules, resources, and any other components listed in the assembly manifest.
    • Code files are called modules.
  • The assembly manifest is typically included in the main assembly module and contains essential identification information, including which pieces belong to the assembly.
  • If you change any of the referenced files without updating the assembly manifest, you will break the manifest and the assembly’s validity.
  • **ILMerge** utility combines multiple modules and their manifests into a single file assembly.
• Technically an assembly can contain more than one code module which has used several different languages.
• Assemblies are either strongly named or not.
  • A strongly named assembly has a hash code built into its manifest that the loader can use to test the integrity of the assembly to ensure it has not been modified.
  • Assemblies can also be digitally signed in order to identify their producer.

Assembly Version

• **AssemblyVersionAttribute** should be incremented manually.
  • This should be done when you plan to deploy a specific version to production.
• **AssemblyFileVersionAttribute** should be incremented with each build.
  • This is not something you want to do on the client, where it would get incremented with every developer build.
    • You should integrate this into your build process on your build server.

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

Assembly Bindings

• You can deploy multiple versions of the same assembly to the GAC and avoid the DLL problem that happened with regular DLL files.
  • This is called side-by-side hosting, in which multiple versions of an assembly are hosted together on one computer.
• The bindings can be influenced with specific configuration files. Three configuration files are used:
  1. Application configuration files.
  2. Publisher policy files.
  3. Machine configuration files.
• If you have an assembly deployed privately with your application, the CLR starts looking for it in the current application directory.
  • If it can’t find the assembly, it throws a FileNotFoundException.
• You can specify extra locations where the CLR should look in the configuration file of the application using "probing" section:

<configuration>
	<runtime>
		<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
			<probing privatePath="bin;bin2\\subbin;bin3" />
		</assemblyBinding>
	</runtime>
</configuration>

• A codebase element can specify a location for an assembly that is outside of the application’s directory.
• This way you can locate an assembly that’s on another computer on the network or somewhere on the Internet.
• These assemblies have to be strongly named if they are not in the current application’s folder.
• When the assembly is located on another computer, it’s downloaded to a special folder in the GAC.

<configuration>
	<runtime>
		<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
			<dependentAssembly>
				<codeBase version="1.0.0.0" href="<http://www.mydomain.com/ReferencedAssembly.dll>"/>
			</dependentAssembly>
		</assemblyBinding>
	</runtime>
</configuration>