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 maintenant je voudrais la recibler vers .Net 4.5

Ce dont je ne suis pas sûr, ce sont les packages NuGet. Par exemple, EF5, que j'ai mis à jour à partir d'EF4 dans VS2010, se révèle être en fait EF 4.4 comme vous pouvez le voir ici:

    <Reference Include="EntityFramework, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\EntityFramework.5.0.0\lib\net40\EntityFramework.dll</HintPath>
    </Reference>

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

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="EntityFramework" version="5.0.0" targetFramework="net40" />
</packages>

Ma question est donc:

Quelle est la meilleure pratique pour recibler tous les packages NuGet actuellement définis pour cibler .NET 4.0 vers .NET 4.5?

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

NuGet 2.0 ne gère pas très bien le reciblage de vos applications. Pour 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 afin de pouvoir réinstaller chacun d'eux).

La raison pour laquelle les packages doivent être désinstallés et réinstallés est:

• Lors de l'installation d'un package, nous déterminons le cadre cible de votre projet
• Nous faisons ensuite correspondre cela avec le contenu du package, en trouvant le dossier \ lib \ approprié (et le dossier \ content \)
• Les références d'assembly sont ajoutées avec des chemins d'accès qui pointent vers le dossier \ lib \ du package, avec le sous-dossier approprié (\ lib \ net40 par exemple)
• Les fichiers de contenu sont copiés à partir du dossier packages \ content \, avec le sous-dossier approprié (\ content \ net40 par exemple)
• Nous enregistrons le targetFramework utilisé pour installer le package dans le fichier packages.config
• Après avoir modifié le cadre cible de votre projet, les chemins d'accès aux conseils pointent toujours vers net40
• Lorsque vous désinstallez des packages, nous vérifions le targetFramework qui a été enregistré dans packages.config pour voir quelles bibliothèques / contenus du framework 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 eu des problèmes avec la update-package -reinstall <packagename>commande, envisagez de l'exécuter avec -ignoreDependenciesflag, comme ceci:

update-package -reinstall <packagename> -ignoreDependencies

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

Plus d'infos ici .

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

Update-Package <PackageName> -ProjectName <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 des packages à l'échelle, j'ai rencontré une erreur de dépendance (malgré l'utilisation de l' -ignoreDependenciesindicateur), et tous les fichiers packages.config de chaque projet avaient été supprimés. Dans VS2013, il semble que packages.config ne soit pas rincé sur le disque et rajouté jusqu'à ce que toutes les dépendances / références mises à niveau soient reconnectées au projet.

Dans mon cas, ce qui a fonctionné a été de mettre à niveau chaque projet un par un en ajoutant le -ProjectName nom du projet à la update-packagecommande. Dans ce cas, packages.config est mis à jour à mesure que chaque projet est mis à niveau.

Cela peut ne pas être pratique pour les très grandes solutions, mais il semble un compromis raisonnable de continuer à profiter de la mise à niveau automatisée pour autant de projets que possible et d'isoler les problèmes sans que tous les packages.config de votre solution soient supprimés en cas d'échec.

Avec Visual Studio pour Mac 2019, un clic droit sur le dossier Packages affiche l'option 'Retarget' dans le menu. Cela a résolu le problème de reciblage pour tous les packages du projet nécessitant un reciblage. Il semble qu'il n'y ait pas de gestionnaire de packages NuGet dans le menu Outils de Visual Studio pour Mac (au moins dans le mien), je n'ai donc pas pu lancer la console du gestionnaire de packages.