Solution de reciblage de .Net 4.0 à 4.5 – comment recibler les packages NuGet?

J’ai migré une solution qui cible actuellement .NET 4.0 dans VS2010 vers VS2012 et je voudrais maintenant la redirect vers .Net 4.5

Ce dont je ne suis pas sûr, ce sont les paquets NuGet. Par exemple, EF5, que j’ai mis à jour depuis EF4 dans VS2010, s’avère être en réalité EF 4.4, comme vous pouvez le voir ici:

 False ..\packages\EntityFramework.5.0.0\lib\net40\EntityFramework.dll  

Je peux également voir ce qui suit dans packages.config pour le projet:

     

Donc ma question est:

Quelle est la meilleure pratique pour re-cibler tous les packages NuGet actuellement définis pour cibler .NET 4.0 afin de cibler .NET 4.5?

NuGet 2.1 offre une fonctionnalité qui rend cela beaucoup plus simple: il suffit de faire update-package -reinstall -ignoreDependencies partir de la console du gestionnaire de packages.

NuGet 2.0 ne gère pas très bien vos applications. Afin de modifier les frameworks cibles de vos packages, vous devez désinstaller et réinstaller les packages (en prenant note des packages que vous avez installés pour pouvoir les réinstaller).

Les paquets de raison doivent être désinstallés et réinstallés:

  • Lors de l’installation d’un package, nous déterminons le cadre cible de votre projet
  • Nous comparons ensuite cela avec le contenu du paquet, en trouvant le dossier \ lib \ approprié (et le dossier \ content \)
  • Les références d’assemblage sont ajoutées avec les chemins d’access qui pointent vers le dossier \ lib \ du package, avec le bon sous-dossier (\ lib \ net40 par exemple)
  • Les fichiers de contenu sont copiés à partir du dossier packages \ content \, avec le bon sous-dossier (\ content \ net40 par exemple)
  • Nous enregistrons le targetFramework utilisé pour installer le paquet dans le fichier packages.config
  • Une fois que vous avez modifié le cadre cible de votre projet, les chemins d’access suggèrent toujours net40
  • Lorsque vous désinstallez des packages, nous vérifions le targetFramework qui a été enregistré dans packages.config pour voir les bibliothèques / contenus de l’infrastructure cible à supprimer de votre projet.
  • Lorsque vous réinstallez le package, nous détectons votre framework cible mis à jour et référençons / copions les bonnes bibliothèques / contenus.

Pour ceux qui ont des problèmes avec la commande update-package -reinstall , envisagez de l’exécuter avec l’indicateur -ignoreDependencies , comme ceci:

 update-package -reinstall  -ignoreDependencies 

Cet indicateur laissera vos dépendances de paquetage seules, sinon elles pourraient être mises à jour même si le paquet que vous vouliez à l’origine réinstaller conserve toujours sa version.

Plus d’infos ici .

Après avoir essayé la réponse acceptée sans succès, je voudrais suggérer une commande moins risquée:

 Update-Package  -ProjectName  -Reinstall -IgnoreDependencies 

Pour plus d’informations: http://blog.nuget.org/20121231/a-quick-tutorial-on-update-package-command.html

Lors de la tentative de réinstallation de la solution dans sa -ignoreDependencies , j’ai rencontré une erreur de dépendance (malgré l’utilisation de l’indicateur -ignoreDependencies ) et tous les fichiers packages.config de chaque projet ont été supprimés. Dans VS2013, il semble que packages.config ne soit pas vidé sur le disque et rajouté tant que toutes les dépendances / références mises à niveau ne sont pas reliées au projet.

Dans mon cas, cela a fonctionné en mettant à niveau chaque projet un par un en ajoutant le nom de projet -ProjectName à la commande update-package . Dans ce cas, le fichier packages.config est mis à jour à chaque mise à niveau de chaque projet.

Peut ne pas être pratique pour des solutions très volumineuses, mais il semble raisonnable de tirer parti de la mise à niveau automatisée pour autant de projets que possible et d’isoler les problèmes sans avoir à supprimer tous les packages.config de votre solution en cas d’échec.