This chapter covers managed library implementation. It also discusses execution environment concepts and features that you learned about in Chapter 1 (such as assembly, module, manifest, and versioning for a managed environment).
Assemblies, Modules, Manifest, Versioning
All functionalities within a .NET executable Microsoft Intermediate Language (MSIL) are described through one or more assemblies. An assembly is a .NET entity whose purpose is to act as a deployable unit. A module is an MSIL file referenced by a logical name stored in the metadata rather than by its filename.
- .NET 5 assembly System.Runtime
.NET module System.Runtime.dll
- .NET Standard assembly netstandard
.NET module netstandard.dll
- .NET Core assembly System.Runtime
.NET module System.Runtime.dll
- .NET Framework assembly mscorlib
.NET module mscorlib.dll
Assembly
An assembly is a .NET entity whose purpose is to act as a deployable unit in Common Language Runtime (CLR) managed environments and with associated mechanisms, as with execution environments. Assemblies are capable of administration tasks that keep the managed environment and all resources used at runtime in an efficient and safe environment for the planned activities and related functionalities.
An assembly has different kinds of resources stored in files logically grouped for distribution, and not only executable code is stored in files associated with an assembly.
An assembly must have only one manifest among all its files. In addition, in the main assembly that has the entry point and will be executed rather than simply dynamically loaded, the manifest must be stored in that module.
Manifest
An assembly always has a manifest that specifies the assemblies and modules that we are using for our unit of deployment.
Excerpt of Metadata Manifest for Assembly RVJ.Core.Business, Stored in the Module RVJ.Core.Business.dll
Manifest for the RVJ.Core.Business assembly and the RVJ.Core.Business.dll module
Project properties with values for “Assembly version:” assigned to the .ver directive in the manifest and the “Assembly file version” assigned to the .assembly directive in the manifest
Excerpt of Project Source Code for the Definition of the Configuration of a Project, Including .assembly and .module Versions
Module
A module is an MSIL file referenced by a logical name stored in the metadata rather than by its filename.
An Excerpt of the Syntax of the .module Directive for RVJ.Core.Business.dll, Showing the Use of Syntax and Relation for Directives .assembly, .ver, and .module
Listing 6-4 shows a client application named Buffers_Console_Client with a .module directive value assigned with Buffers_Console_Client.dll and with a .assembly directive named Buffers_Console_Client.
We have .assembly extern as the directive informing that our assembly Buffers_Console_Client is referencing the assembly RVJ.Core.Business, and we are not informing that .assembly RVJ.Core.Business has a .module RVJ.Core.Business.dll as part of deployment unit.
A Client Application with .assembly Extern as the Directive Informing That Our Assembly Buffers_Console_Client Is Referencing the Assembly RVJ.Core.Business. We Are Not Informing That .assembly RVJ.Core.Business Has a .module RVJ.Core.Business.dll as Part of Deployment Unit
An example of MSIL for a manifest of the assembly Buffers_Console_Client stored in the module Buffers_Console_Client.dll
Versioning
The version number of an assembly module is specified using the .ver directive. For RVJ.Core.Business, the .assembly directive with a value uses a sequence of four 32-bit integers in the format Int32:Int32:Int32:Int32 (as with 6:0:0:0 for the System.Reflection.AssemblyFileVersionAttribute attribute for the .module directive with a value using Int32:Int32:Int32:Int32, as we have with file RVJ.Core.Business.dll with value of 5:0:0:0).
Version numbers are captured at compile time and used as part of all references for the assemblies within each compiled module.
Major version number: Assemblies with the same name and with different major versions are considered not interchangeable, and the first of these 32-bit integers is considered the major version number. That major version number is used for a major rewrite of a product where backward compatibility will not be guaranteed (even by formal business contracts).
Minor version number: Assemblies with the same name and same major version. This is the point for the use of the second of these 32-bit integers called the minor version number. It is used to indicate improvements and enhancements in each different minor version.
The minor version number can also be used to indicate significant improvements, but with the intention of being backward compatible, where possible, or meaning a fully backward-compatible new version of a product.
Build version number: At the time of this writing, we have the same software available in different hardware and operating system platforms. The third of these 32-bit integers is considered the build number and is recommended for recompilation of the same source code base for different target platforms—operating system, hardware processor, or even development tool changes or updates (for example, with integrated development environments [IDEs]).
Revision version number: The revision number is used when we have assemblies with the same name, the same major version, and the same minor version, but that requires a revision. The idea of a revision is to be fully interchangeable.
This is the recommendation for the fourth of these 32-bit integers. A good example is a security hole fix (common today) or improvements in internal algorithms.