web-dev-qa-db-fra.com

Utilisation de deux versions différentes du même package nuget

Je voulais utiliser deux versions différentes de la même bibliothèque (OpenCVSharp 2.x et OpenCVSharp 3.x) Eh bien, j'ai téléchargé ces deux packages à la fois dans le projet séparé (appelons-le OCV2Wrapper et OCV3Wrapper) et référence les deux wrappers dans mon projet. J'ai dû renommer les bibliothèques d'un package (2.x) et les référencer manuellement parce que: Peut-on ajouter 2 versions différentes du même package dans NuGet . J'ai lu des alias externes et j'ai utilisé un alias externe dans l'un des wrappers (2.x dans mon cas). Mais j'ai des problèmes majeurs:

  • Mes bibliothèques renommées ne sont pas copiées dans la génération du projet de lancement (celle qui fait référence aux deux wrappers), mais se trouve dans la build du wrapper 2.x
  • Cela ne fonctionne pas car il dit que je ne trouve pas le type à partir de mon wrapper 2.x même lorsque je copie manuellement mes bibliothèques renommées à partir du wrapper 2.x.

Quelle est la bonne approche pour ce scénario en C #?

Je veux utiliser les deux wrappers en solution car la version 2.x contient des algorithmes (SIFT et SURF) et la version 3.x contient des algorithmes (Kaze et AKaze). Je peux vivre que les deux paquets seraient hors de nuget mais je préfère que 3.x soit de nuget et que la version 2.x soit configurée manuellement.

c#.netreferencelibraries
19
LightCZ

Comme déjà indiqué, il n'y a rien de mal à référencer 2 versions différentes d'un package de nugget, tant que c'est dans différents projets Visual Studio que ces références sont faites.

Mais c'est aussi là que se termine la partie facile, mais je pense qu'il reste quelques options. Selon vos besoins, je vois les options suivantes.

  1. Créez une étape de post-génération qui enregistre les assemblys à plusieurs versions dans le GAC. Tant que chaque assemblage a une version d'assemblage différente, le CLR récupérera le bon assemblage du GAC en cas de besoin.
  2. Créez une étape de post-construction qui copie les différents assemblys dans un sous-dossier de votre dossier bin d'application comme bin/package-v1 et bin/package-v2 . Ensuite, vous pouvez dans votre application remplacer l'événement AssemblyResolve comme décrit ici https://msdn.Microsoft.com/en-us/library /ff527268(v=vs.110).aspx . Cela vous permettra de charger l'assemblage dans la bonne version au moment où vous en aurez besoin.
  3. Si vous ne voulez pas jouer avec AssemblyResolve , vous pouvez également modifier votre web/app.config pour effectuer la redirection/vérification de l'assembly comme décrit ici https://msdn.Microsoft.com/en-us/library/4191fzwb (v = vs.110) .aspx =

J'espère que cela vous aidera un peu, afin que vous n'ayez pas à modifier le code source tiers la prochaine fois.

13
ahybertz

OK donc, je résous ce problème en téléchargeant le code source entier pour la version wrapper 2.X. Renommé son espace de noms en ABCDEF2 où ABCDEF était l'espace de noms d'origine. Construisez mon propre paquet de nuget avec ma propre clé et ... publiez-le sur notre serveur de nuget privé. C'est une telle solution boiteuse mais il n'y a pas d'autre moyen que de télécharger manuellement les packages d'origine et de le référencer directement avec un nom de fichier différent, etc. et vous perdez les avantages du nuget.

1
LightCZ