I have a scenario where I have multiple versions of the same assembly that I need to store in the application private folders, in a structure like this:
.\My.dll // latest version, say 1.1.3.0 .\v1.1.1\My.dll // version 1.1.1.0 .\v1.1.2\My.dll // version 1.1.2.0 My problem is that the .Net runtime, when asked for one of the older versions, always finds the latest version and then fails due to build number mismatch before trying to probe for a better match.
The assemblies are strong named and I’m using this configuration in my app.config:
<runtime> <assemblyBinding xmlns='urn:schemas-microsoft-com:asm.v1'> <dependentAssembly> <assemblyIdentity name='My' publicKeyToken='xxxxxxxx' culture='netural' /> <bindingRedirect oldVersion='1.0.0.0-1.1.1.0' newVersion='1.1.1.0' /> <bindingRedirect oldVersion='1.1.3.0-1.1.65535.65535' newVersion='1.1.3.0' /> <codeBase version='1.1.1.0' href='v1.1.1\My.dll' /> <codeBase version='1.1.2.0' href='v1.1.2\My.dll' /> </dependentAssembly> </assemblyBinding> </runtime> Hopefully there is something I have missed here. I know this can be solved in code by listening for the AppDomain.AssemblyResolve event but I would love to see a pure config solution.
Update: So I found the bug, which is as Kent assumed, a typo. culture='netural' should be culture='neutral'. That said, without the typo, resolving works great when using codeBase elements that point to each version. The probing element does not seem to work in this scenario.
Without seeing the entire solution, I can only assume you have a typo somewhere. I just tried this for myself and – with the help of fuslogvw, I was able to get it working.
I have three versions of the assembly and the consuming application references an older version than that in its output directory. The CLR finds the redirects and codeBase entry and loads the correct (older) version.
I can email you my solution if you provide an email address.
Kent