CODEWITHSUNDEEP
c#.netassemblies
Mortana
Mortana

Reputation: 1442

Runtime throws method not found - referenced assembly version mismatch

I have a class library that references a specific 3th-party DLL. This DLL changes versions very often, but is always backwards compatible within the same major version. My class library uses specific types of the DLL, and executes different methods contained in these 3th-party DLLs.

I have to rethink the design of the app here, as I have one current issue but will have a bigger issue once there will be multiple major versions of the 3th-party DLL (there will be a limited set of major versions, 3 to be specific).

  1. How can I make sure I can use a different version of the referenced assembly than the one which was originally used during compile-time? My runtime now loads in a DLL which is of a higher minor version, but which throws a 'Method not found' exception. I've removed the tag, as well as trying to execute the Assembly.Load to simulate any behavior when specifying the newer DLL, but both yield the same result; method not found.

  2. What is the best approach to support three major (!) versions of referenced dlls within a single DLL? Because of the nature of the usage of the class library, it's not possible to either allow the user to choose the correct version or build 3 different DLLs.

Upvotes: 0

Views: 362

Answers (1)

Eugene Komisarenko
Eugene Komisarenko

Reputation: 1543

If there is chance of your vendor breaking binary code compatibility and you cannot influence what one is doing there is no simple solution to this problem. Late binding would be one of the workarounds to deal with this in C# using reflection or dynamic, but it will come with the cost of the run-time performance and extremely increased complexity of your code.

If you are set to build this integration layer anyway, you would have to code for all three versions to cover known permutations between them and Adapter might be a good design pattern to start looking into. You would make sure the differences and the entities from the external library are not spilled out of the integration layer into your own business logic hence a lot of conversion logic would be required to isolate the fragile library from the rest of the code. Variations like differences in the types, methods, signatures, behavior and exceptions being thrown would have to be encapsulated and confined.

You would also have to re-design your application or presentation layer whichever depends on this hostile library to deal with the differences accordingly and make it rely only on your own wrappers.

Your integration tests would have to be execute against all three versions of the vendor library constantly possibly on every single time you check in code to the repository so you have enough protection and agility to move forward. And since the vendor keeps working on the code of the library you have to allocate enough time for the constant maintenance and support of the compatibility layer.

Upvotes: 1

Related Questions