3

I'm working on an tool that uses .NET assemblies from another product. A handful of the assemblies are statically referenced in my project (using "Add Reference") because I need to actually use those types in my code. But I load many other assemblies dynamically from the install directory of the product, using reflection to dynamically instantiate whatever objects I need.

I don't want to have to recompile and publish a separate version of my project for every possible version of the product I depend on. Some version of the assemblies I need will definitely be present in the application install directory, so I'd like to use whatever version of the assembly happens to be installed. But it will probably not be exactly the same version as the assembly that I originally used when building my tool. (The product versioning strategy is such that all the assemblies in the product have the same version number, which changes every release, even if the particular assemblies I need static references to haven't changed since the previous release, or support 100% of the APIs I require).

Is it possible to achieve this?

Assembly Version redirects allow me to load a particular version of an assembly when a different version of that assembly is requested. My situation is the inverse of that; I want to load whatever version happens to be present.

Hydrargyrum
  • 3,378
  • 4
  • 27
  • 41
  • Are you referring to the statically referenced or dynamically loaded assemblies? – Jeff Dec 10 '15 at 02:37
  • I want to statically reference assemblies in my build process, and then (at runtime) *actually use* the copies already present on the target machine (which might be a slightly different version). – Hydrargyrum Dec 10 '15 at 02:52
  • The dynamically loaded assemblies are no problem, except when they themselves statically reference a different version of the same assemblies that I referenced when building my tool, resulting in conflicts and incompatible types that should be compatible. That's why I want to load the version that is present in the install folder rather than ship my own copy. Maybe that's the wrong approach? – Hydrargyrum Dec 10 '15 at 02:54
  • 2
    You still use a bindingRedirect. You ask for, say, version 1.0.0.0 and you are happy about getting any version. The key is to always use the same reference assembly so you always ask for 1.0.0.0. Make a copy now, check it into source control. You *will* regret this sooner or later. Later. – Hans Passant Dec 10 '15 at 20:32

1 Answers1

3

You can bind to the AppDomain.CurrentDomain.AssmeblyResolve event and handle resolution yourself.

Jeff
  • 35,755
  • 15
  • 108
  • 220
  • This is how most of the assemblies are resolved dynamically (based on assembly name only). I didn't realise it would work to load a statically referenced assembly with a different strong name (due to differing version number). I'll give it a shot. – Hydrargyrum Dec 11 '15 at 03:35
  • For reference, I've found some documentation which explicitly says [The event handler can return a different version of the assembly than the version that was requested.](https://msdn.microsoft.com/en-us/library/ff527268(v=vs.110).aspx) – Hydrargyrum Dec 11 '15 at 03:53
  • Yep, this approach works. All I needed to do was delete the mismatching assemblies that were getting included in my project output folder so that the runtime didn't load them first, and then everything is loaded dynamically, with matching consistent versions, from the same folder. – Hydrargyrum Dec 11 '15 at 08:53