How does assembly versioning work?
An assembly has a version number consisting of four parts, e.g. 1.0.350.1. These are typically interpreted as Major.Minor.Build.Revision, but this is just a convention. The CLR applies no version constraints on weakly named assemblies, so the assembly version has no real significance. For strongly named assemblies, the version of a referenced assembly is stored in the referring assembly, and by default only this exact version will be loaded at run-time. If the exact version is not available, the referring assembly will fail to load. It is possible to override this behaviour in the config file for the referring assembly – references to a single version or a range of versions of the referenced assembly can be redirected to a specific version. For example, versions 1.0.0.0 to 2.0.0.0 can be redirected to version 3.0.125.3. However note that there is no way to specify a range of versions to be redirected to. Publisher policy files offer an alternative mechanism for redirecting to a differe
Each assembly has a version number called the compatibility version. Also each reference to an assembly (from another assembly) includes both the name and version of the referenced assembly. The version number has four numeric parts (e.g. 5.5.2.33). Assemblies with either of the first two parts different are normally viewed as incompatible. If the first two parts are the same, but the third is different, the assemblies are deemed as ‘maybe compatible’. If only the fourth part is different, the assemblies are deemed compatible. However, this is just the default guideline – it is the version policy that decides to what extent these rules are enforced. The version policy can be specified via the application configuration file. Remember: versioning is only applied to shared assemblies, not private assemblies.
An assembly has a version number consisting of four parts, e.g. 1.0.350.1. These are typically interpreted as Major.Minor.Build.Revision, but this is just a convention. The CLR applies no version constraints on weakly named assemblies, so the assembly version has no real significance. For strongly named assemblies, the version of a referenced assembly is stored in the referring assembly, and by default only this exact version will be loaded at run-time. If the exact version is not available, the referring assembly will fail to load. It is possible to override this behaviour in the config file for the referring assembly – references to a single version or a range of versions of the referenced assembly can be redirected to a specific version. For example, versions 1.0.0.0 to 2.0.0.0 can be redirected to version 3.0.125.3. However note that there is no way to specify a range of versions to be redirected to. Publisher policy files offer an alternative mechanism for redirecting to a differe
Related Questions
- Is the implementation of EBG structures into printed circuit boards something that can be done with standard PCB design and assembly processes, or would a new tool set need to be developed?
- How does dbVar place data submitted on one assembly (e.g., NCBI36) on other assemblies (e.g., GRCh37)?
- How does assembly versioning work?
