33

I wanted to use two different version same library (OpenCVSharp 2.x and OpenCVSharp 3.x).

I downloaded those two packages both to the separate project (let's 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 manual 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 doesn't work because yet it says it cannot find a 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 the 2.x version contains algorithms (SIFT and SURF) and 3.x version contains algorithms (Kaze and AKaze).

I can live that with both packages coming from somewhere other than NuGet, but I prefer that 3.x comes from NuGet and the 2.x version is manually configured.

Tu deschizi eu inchid
  • 4,117
  • 3
  • 13
  • 24
LightCZ
  • 695
  • 1
  • 8
  • 20
  • You stated that you have created at least three projects in your solution, correct? The limitation of the question you have posted is for one project. You can add different versions of a nuget package to different projects without any problem. And as long as your two projects handle the code of the nuget package and you reference the two in your third project everything should be fine – Manuel Zelenka Jan 15 '16 at 02:18
  • 1
    OK i get that. BUT when i do that (use two wrappers for two different libraries) then in my build of executable program i dont have libraries from 2.x wrapper (which are manually referenced from browse file and renamed so i would prevent name overwrite conflict) – LightCZ Jan 15 '16 at 13:36
  • Confirmed the behavior, I also don't see Nuget automatically get the lower version library – Hoàng Long Apr 06 '16 at 02:41

2 Answers2

26

As already stated, there is nothing wrong with referencing 2 different versions 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 registers 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 copies the different assemblies into a subfolder of your application bin folder like bin/package-v1 and bin/package-v2. Then you can, in your application, override the AssemblyResolve event as 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.

Pang
  • 9,564
  • 146
  • 81
  • 122
ahybertz
  • 514
  • 4
  • 9
  • 1
    Yeah, this is totally true and probably it would be working. For me, it was much faster to refactor source code of one package and rebuild it with different namespace and package id – LightCZ Jun 07 '18 at 08:51
  • 1
    I am marking this one as an answer, since this question is getting a lot of attention and this solution is like a real solution. – LightCZ Jul 24 '18 at 22:47
6

OK so, I solve this by downloading whole sourcecode for 2.X wrapper version. Renamed its namespace to ABCDEF2 where ABCDEF was original namespace. Build my own nuget package with my own key and... publish it to our private nuget server. This is such a lame solution but there is no other way than manually downloading the original packages and reference it directly with different filename etc and you loose nuget advantages.

LightCZ
  • 695
  • 1
  • 8
  • 20