Binding Redirects (or Version Redirects) & *.config Files

First, the runtime checks the configuration files ([app].config, publisher policy or the machine.config, in this order) for any elements that might impact the version of assembly that should be bound. This example basically tells the app, "If your manifest says you need assembly 1.5.42.1 (or anything in the "oldVersion" range), then load version 2.0.0.0 instead." This instruction could be in any of the configuration files. The assembly must also be strongly named to be redirected in this manner.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
        <assemblyIdentity name="someAssembly"
            publicKeyToken="8cb93028ef92ac93"
            culture="neutral" />
        <bindingRedirect
            oldVersion="1.0.0.0-1.65535.65535.65535"
            newVersion="2.0.0.0"/>
    </dependentAssembly>
</assemblyBinding>

The runtime first checks the [app].config file, which (if present) should be in the application's directory. Next it checks the publisher policy file, which is essentially a different assembly installed in the GAC that affects all applications that use the shared assembly. Any changes in the publisher policy file override those in the application manifest and in the [app].config file. Finally, it checks the machine.config file, which overrides all other settings and basically has the final say. If none of the files overrides the executing assembly’s manifest, then the runtime looks for the assembly in the manifest.

To Load or Not To Load

Now the runtime has the name of the assembly to load, strong or weak. If an assembly of the same name has already been loaded, it will use the pre-loaded assembly instead of loading a new copy of it. If the names are weak, then version numbers will not be compared, which could cause problems. For example, if the weakly-named assembly MyDal.dll (version 1.0) was previously loaded because some other dependency needed to run some code in it, and your code next needed to run some code in MyDal.dll (version 2.0), then the 2.0 version would never be loaded; Because of the weak names, the runtime will see that assembly "MyDal" had already been loaded and will try to use that instead.