Using two different versions of same the nuget package

Question

I wanted to use two different version same library (OpenCVSharp 2.x and OpenCVSharp 3.x) Well i downloaded those two packages both to the separate project (lets call it OCV2Wrapper and OCV3Wrapper) and reference both wrappers in my project. I had to renamed libraries from one package (2.x) and reference them manualy because: Can we add 2 different versions of same package in NuGet. I read about external aliases and I used external alias in one of the wrappers (2.x in my case). But I have some major problems:

• My renamed libraries are not copied to the launch project build (that one which reference both wrappers), but is in build of the 2.x wrapper
• It dont work because yet it say cannot find type from my 2.x wrapper even when I manually copy my renamed libraries from 2.x wrapper.

What is the correct approach for this scenario in C#?

I want to use both wrappers in solution because 2.x version contains algorithms (SIFT and SURF) and 3.x verison contains algorithms (Kaze and AKaze). I can live that both packages would be out of nuget but i prefer that 3.x is from nuget and 2.x version is manually configured.

Answer 1

As already stated there is nothing wrong with referencing 2 different versions of of a NuGet package, as long as it's in different Visual Studio Projects that those references are made.

But this is also where the easy part ends, but I think there are a few options left. Depending on your needs I see the following options.

1. Create a post build step which register the multi-versioned assemblies into the GAC. As long as each assembly have different assembly version, the CLR will pick up the right assembly from the GAC when needed.
2. Create a post build step which copy the different assemblies into a subfolder of you application bin folder like bin/package-v1 and bin/package-v2. Then you can in your application override the AssemblyResolve event like described here https://msdn.microsoft.com/en-us/library/ff527268(v=vs.110).aspx. This will make it possible for you to load the assembly in the right version at the time of need.
3. If you don't want to play around with AssemblyResolve, then you can also modify your web/app.config to do assembly redirect/probing as described here https://msdn.microsoft.com/en-us/library/4191fzwb(v=vs.110).aspx

Hope this helps a bit, so you don't have to modify third party source code next time.