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. I will leave it up to the reader to spot it. That said, without typos resolving works great when using codeBase tags that points to each version. The probing tag does not seem to work in this scenario.
-
Can you use a probepath? we use this to force uncontrolled (e.g. third party resolvers - such as MSTest) to look for assemblies where we need them to be.
<?xml version ="1.0"?> <configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <probing privatePath="v1.1.1;v1.1.2;"/> </assemblyBinding> </runtime> </configuration>
See here for more info
Peter Lillevold : Hm, I have to withdraw my vote. It seems that I cannot get this to work only using the probing tag. -
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
Peter Lillevold : Great, you can send it to resolve at dezibel.comKent Boogaart : OK, I've sent it.Peter Lillevold : Hmm, sorry, seems that my catch-all is not working. Could you please resend to peter at dezibel.com ?Peter Lillevold : Mind not to include any executables in that mail though, most systems block such content even if they are "hidden" in zip-files..Kent Boogaart : When is SO make this kind of thing easier? OK, resent it without any bin/obj folders in it. The only time I've seen a mail system that inspects zip files was at an investment bank, and it drove everyone nuts. People just renamed their zip files to *.zip.renamedKent Boogaart : I got a delivery failure notification for your underlying gmail address.Peter Lillevold : I got the source, Kent, thanks. Me too vote for SO features for better user-to-user interaction. Anyways, your code is working fine, but while trying it out in various ways I realized that there is more to my problem than I have described here. Update coming soon.