Assembly manifest records information about the version of
each dependency it was built against. However, as stated in the above example
where the developer of APP2 may wish to run with a
different version of a dependency at run time. The .NET Framework enables this
flexibility in version binding through version policies.
Assembly Version Numbers
The parts of the version number are major, minor, build and
revision. As a developer you are free to change any portion of this number as
you see fit.
One typical convention is as follows.
Major or minor: Changes to the major
or minor portion of the version number indicate an incompatible change. Under
this convention then, version 2.0.0.0 would be considered incompatible with
version 1.0.0.0.
Build: The Build number is typically
used to distinguish between daily builds or smaller compatible releases.
Revision: Changes to the revision
number are typically reserved for an incremental build needed to fix a
particular bug. You will sometimes hear this referred to as the "emergency
bug fix" number in that the revision is what is often changed when a fix
to a specific bug is shipped to a customer.
Default Version Policy
The CLR determines which version of the dependency to load
when it comes across a reference to that assembly in code. The default version
policy in .NET is simple, the caller gets the exact version with which the
application was built and tested against.
Custom Version Policy
This is the section we have been talking so long where the
author does not want the CLR to load the default version and redirects the CLR
to the other version defined by the Author.
Version policies are stated in XML files and are simply a
request to load one version of an assembly instead of another.
Example 3
The following version policy directs the CLR to load version
2.0.0.0 instead of version 1.0.0.0 of an assembly called app1.engine.
Listing 1
<configuration>
<runtime>
<assemblyBinding
xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity
name=" app1.engine"
publicKeyToken="ebf6b2ff4d0a08aa" />
<bindingRedirect oldVersion="1.0.0.0"
newVersion="2.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
This is just a simple XML file. The name of this file is policy.1.0.app1.engine.config. Just place the file exactly
where app1.engine.dll exists, in case of shared assembly it may be GAC.
Example 4
You can also redirect from a range of versions to another
version. For example, the following policy redirects all versions from 1.0.0.0
through 5.0.0.0 of app1.engine to version 7.0.0.1.
Listing 2
<configuration>
<runtime>
<assemblyBinding
xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity
name=" app1.engine"
publicKeyToken="ebf6b2ff4d0a08aa" />
<bindingRedirect oldVersion="1.0.0.0-5.0.0.0"
newVersion="7.0.0.1"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
This file is also similar to above example.
