Geek Answers Handbook

Using two different versions of the same nuget package

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

  • My renamed libraries are not copied to the startup project assembly (the one that references both wrappers), but is in the 2.x shell assembly
  • It does not work, because for now it cannot find the type from my 2.x shell even when manually copying the renamed libraries from the 2.x shell.

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

I want to use both shells in the solution because version 2.x contains algorithms (SIFT and SURF) and 3.x verison contains algorithms (Kaze and AKaze). I can live that both packages will be from nuget, but I prefer that 3.x from nuget and 2.x be manually configured.

+6
source share
2 answers

So, I solve this by downloading all the source code for version 2.X. Renamed its namespace to ABCDEF2, where ABCDEF was the original namespace. Create your own nuget package with my own key and ... publish it on our private nuget server. This is such a lame solution, but there is no other way than manually downloading the source packages and linking to it directly with different file names, etc., and you will lose the benefits of nuget.

0
source

As already mentioned, there is nothing wrong with linking to 2 different versions of the nugget package if these links are made in different Visual Studio projects.

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.

  • Create an assembly step that registers several versions in the GAC assembly. As long as each assembly has a different version of the assembly, the CLR will assemble the desired assembly from the GAC when necessary.
  • Create a post-build step that copies the various assemblies into a subfolder of your application bin folder, for example bin / package-v1 and bin / package-v2 . You can then override the AssemblyResolve event in your application, as described here https://msdn.microsoft.com/en-us/library/ff527268(v=vs.110).aspx . This will allow you to download the assembly in the correct version when necessary.
  • If you do not want to play with AssemblyResolve , you can also change your web / app.config to redirect / probe the assembly, as described here https://msdn.microsoft.com/en-us/library/4191fzwb(v=vs .110) .aspx

We hope this helps a bit, so you won’t have to modify the source code of a third party in the future.

+5
source

More articles:


All Articles