My application references an assembly that increases in version a lot.
I can set “Specific Version” in my Visual Studio reference to false so that I don’t encounter any build issues but I need to be able to work with any version at runtime.
As far as I can see I have two options:
-
Request that the publisher of the dll uses a Publisher Policy File and adopts Assembly Binding Redirection.
-
Dynamically load the assembly using
Reflection.
Now, with option 1, there is a chance that the assembly supplier can not be persuaded to use this technique. I am pre-empting this as the supplier would have quite a lot of large redirects in their config due to the number of releases of this assembly.
With option 2, I would prefer not to use Reflection in this instance as I want to maintain the flexibility and ease that VS Intellisense brings.
So, my question is: Is there a 3rd option or are my concerns about the first two options of no real significance?
Option 2a: Use reflection to load it in release builds only. Override the AssemblyResolve event and load the assembly manually if it fails due to a versioning conflict.
Option 3: Don’t change the version number. (Put it in a different field in the assembly info if you want a build number so you can tell different builds apart, but if the exposed API doesn’t change, don’t consider it to be a new version)