Les paquets NuGet sont manquants

J'ai résolu mon problème en supprimant ce code du fichier .csproj:

<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
  <PropertyGroup>
    <ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
  </PropertyGroup>
  <Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>

Si vous avez un autre paquet nuget manquant qui donne votre erreur lors de la construction de votre solution, utilisez la commande suivante en utilisant la Console de commandes Nuget depuis Outils > Gestionnaire de paquets Nuget > Console du Gestionnaire de paquets. Il réinstallera tous vos paquets actuels.

Update-Package –réinstaller

Méfiez-vous - cela met à jour les paquets pour l'ensemble de la solution et pas seulement le projet.

J'ai eu ce message frustrant exact. Ce qui a finalement fonctionné pour moi a été de supprimer tous les fichiers et dossiers à l'intérieur /packages et de laisser VS tout récupérer la prochaine version.

Tiberiu a raison. J'ai dû modifier mon .fichier csproj que les fichiers ont été déplacés et a causé ce problème

 <Import Project="..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.1\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.1\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />

J'ai changé au début du fichier et en bas

<Error Condition="!Exists('..\..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props')" Text="$([System.String]::Format('$(ErrorText)', '..\..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props'))" />
<Error Condition="!Exists('..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.1\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.1\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />

J'ai résolu ce problème en supprimant le code suivant de .fichier csproj

<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
  <ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\..\..\Assemblies\NuGet\SpecFlow.Plus.Excel.1.4.2\build\SpecFlow.Plus.Excel.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\..\..\Assemblies\NuGet\SpecFlow.Plus.Excel.1.4.2\build\SpecFlow.Plus.Excel.targets'))" />

Une combinaison des 2 réponses a fonctionné pour moi. D'abord j'ai modifié le .fichier csproj pour supprimer la référence à la version 1.0.0

< Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild" >

  ----Error---

< /Target>

Et ensuite fait

Update-Package -Reinstall

De la et cela a fonctionné.

Il suffit d'activer la restauration du paquet NuGet. Faites un clic droit sur votre solution > choisissez "Activer la restauration du Package NuGet".

Cela va créer le .dossier nuget avec NuGet.Fichier de configuration et correction de mon problème.

J'utilise VS2012 et face à la même erreur. J'ai supprimé la balise cible suivante de la .fichier csproj et il a commencé à compiler sans erreur.

<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
  -- Error messages within Target Tag
</Target>

Pour moi, le problème était que lorsque j'ai copié la solution dans un nouveau dossier et l'ai ouverte, il manquait le dossier Nuget comme indiqué ci-dessous. J'ai copié ce dossier et tout a fonctionné. Note: ce même dossier était dans notre contrôle de source mais pas dans ce projet de solutions, il était dans un répertoire.

Pour développer quelques-unes des réponses ici, oui, vous pouvez supprimer le bloc suivant de votre .fichier csproj:

<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">

Et cela résout le problème, mais dans mon cas, j'ai remarqué que j'avais des références supplémentaires aux compilateurs.NET. et .CodeDom.Fournisseurs avec différentes versions:

<Error Condition="!Exists('..\packages\Microsoft.Net.Compilers.1.0.0
<Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\

<Error Condition="!Exists('..\packages\Microsoft.Net.Compilers.2.0.1
<Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.3\

Quand mes paquets.config n'a référencé que les éléments suivants:

<package id="Microsoft.Net.Compilers" version="2.0.1"
<package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.3"

Suppression des éléments 1.0.0 du.fichier csproj a corrigé le problème.

Pour tous ceux qui trébuchent ici avec le problème que j'avais (certains paquets mais pas tous en cours de restauration sur un serveur de construction), la dernière pièce du puzzle pour moi était d'ajouter un NuGet.config dans la racine de ma solution, frère à la .Fichier SLN comme David Ebbo l'a expliqué ici: http://blog.davidebbo.com/2014/01/the-right-way-to-restore-nuget-packages.html .

De L'article de blog D'Ebbo, le contenu du fichier pour moi est simplement

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>
</configuration>

Mise à jour:

L'URL de L'API NuGet a changé pour v3 (en vigueur à partir de septembre 2016). À partir de https://www.nuget.org/

<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />

Le message d'erreur est complètement correct. J'ai essayé tous les trucs et aucun n'a fonctionné. Le projet (simple MVC Web App test) déplacé de Windows 8.1 VS 2015 Communauté à ma nouvelle boîte de test sur Windows 10. Toutes les dernières mises à jour de VS 2015 appliquées. Je ne pouvais même pas installer une version plus récente du paquet compilateurs.

Loop:
<LOOP>This seems to be a Ground Hog Day phenomena.</LOOP>
GoTo Loop

J'ai finalement juste copié Microsoft.Net.Compilers.1.0.0 de L'ancien projet dans le nouveau et cela a fonctionné. Je pourrais alors commencer à mettre à jour d'autres paquets à plus récent version. On dirait un bug de processus de mise à niveau du projet nuget pour moi.

Remarque: le projet d'origine a été créé dans VS 2015 et n'a pas de méthodologies NuGet héritées.

Solution qui fonctionne dans mon cas - Visual Studio 2015 Enterprice, project. net 4.6.1

1. Mise à niveau vers la mise à jour 3
2. Installer les outils de développement Web

Pour moi, les paquets étaient là sous le chemin correct, mais les dossiers de construction à l'intérieur du dossier de paquet ne l'étaient pas. J'ai simplement supprimé tous les paquets qu'il disait manquants et reconstruit la solution et il a créé avec succès les dossiers de construction et le .accessoires de fichiers. Donc, les messages d'erreur étaient corrects en m'informant que quelque chose était un échec.

Je n'ai trouvé aucune solution à cela, j'ai donc ajouté une copie du nuget.exe et un script powershell dans le répertoire racine de la solution appelée prebuild. ps1 avec le contenu suivant.

$nugetexe = 'nuget.exe'
$args = 'restore SOLUTION_NAME_HERE.sln'
Start-Process $nugetexe -ArgumentList $args

J'ai appelé ce script powershell dans ma construction dans le chemin du script de pré-construction

Le mien a fonctionné quand j'ai copié le dossier de paquets avec le fichier de solution et le dossier de projet. Je n'ai tout simplement pas copié le dossier packages de l'endroit précédent.

Vous pouvez également utiliser le message d'erreur suggéré comme indice. Voici comment, trouvez les Packages gérer pour la Solution, et cliquez sur le package résoudre NuGet manquant.

C'est tout

Commentez l'Option du compilateur dans WebConfig:

<!--<system.codedom>
<compilers>
  <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701" />
  <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:14 /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" />
</compilers>
</system.codedom>-->

Mettre à jour la dernière Version des paquets dans le fichier de configuration des paquets

  <package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.4" targetFramework="net452" />

Reconstruire si tout est ok, pas besoin de continuer, sinon Cliquez avec le bouton droit sur le projet, cliquez sur "Décharger le projet" Cliquez-droit sur le projet et les modifier .fichier csproj

Validez le chemin de Codedom, il n'avait pas net45 dans les chemins précédents, ajoutez-le manuellement, enregistrez, chargez, reconstruisez. Il devrait fonctionner.

<Import Project="..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.4\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.4\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />

Comme beaucoup l'ont suggéré, la suppression de la balise <Target> peut la rendre compilable. Pourtant, méfiez-vous du fait que cela a un effet secondaire lorsque vous le faites pour des projets de test.

J'ai eu une erreur liée au paquet MSTest.TestAdapter nuget lors de la compilation. Résolu ce problème en supprimant la balise <Target>. Bien qu'il ait réussi à construire, les méthodes de test sont devenues non découvrables. Test explorer ne répertorie pas les méthodes de test dans ce projet et exécuter Test ou Debug Test ne fonctionnera pas aussi bien.

J'ai rencontré ceci en utilisant Visual Studio 2017 et .Net framework 4.7, il peut très bien se produire dans d'autres versions

Le problème pour moi était que NuGet ne pouvait pas automatiquement obtenir/mettre à jour les paquets car le chemin d'accès complet du fichier serait trop grand. corrigé en déplaçant ma solution vers un dossier dans Mes Documents au lieu d'un dossier profondément imbriqué.

Ensuite, vous pouvez faire un clic droit sur solution et sélectionner "restaurer les paquets NuGet" (ce qui n'est probablement pas nécessaire si vous le construisez et le laissez le faire pour vous), puis sélectionnez "Gérer les paquets NuGet pour la Solution" pour obtenir tous les paquets mis à jour au plus tard version.

C'était pour une solution d'un exemple D'application ASP MVC téléchargée à partir du site Web de Microsoft.

Pour les ingénieurs DevOps/build, vous pouvez probablement résoudre ce problème en cours d'exécution nuget restore contre le SLN affecté, ou le projet si vous n'avez pas de SLN. Je dois le faire pour nos builds CI / CD pour tous nos projets UWP.

1. assurez-vous que nuget est installé sur l'esclave build dans Visual Studio ou standalone. Si c'est le dernier, assurez-vous qu'il est dans le chemin et sautez l'étape 2.
2. ouvrez la console cmd VS Dev ou chargez-la via une console déjà ouverte, ce que vous pouvez faire avec les instructions ci-dessous:
   VS2015 call "%VS140COMNTOOLS%VsDevCmd.bat"
   ou
   VS2017 call "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\VsDevCmd.bat"
3. call nuget restore MyStuff.SLN ou call nuget restore MyStuff.csproj s'il n'y a pas de SLN.

Je ne sais pas si cela aidera quelqu'un, mais ce problème est apparu lorsque j'ai supprimé le code source de ma machine locale sans avoir jamais enregistré le fichier de solution sur TFS. (Pendant le développement initial, je faisais un clic droit et vérifiais le projet dans L'Explorateur de solutions, mais j'ai oublié de vérifier la solution elle-même.) Quand je devais travailler sur ce nouveau, tout ce que j'avais dans TFS était le .fichier csproj, Non .la sln fichier. Donc, dans VS j'ai fait un fichier - > Contrôle de Source - > Avancé - ouvert à partir du serveur et ouvert le .fichier csproj. De là, je L'ai fait sauver tout et il m'a demandé où je voulais sauver la .la sln fichier. J'essayais de sauver ce .fichier sln dans le répertoire du projet avec les autres dossiers (App_Data, App_Start, etc.), et non pas le répertoire de niveau supérieur. J'ai finalement compris que je dois sauver la .fichier sln vers le haut d'un répertoire à partir du dossier du projet de sorte qu'il est au même niveau que le dossier du projet. Tous mes chemins se sont résolus et j'ai pu le reconstruire.

J'ai eu ce problème comme une construction échouée dans Azure, lorsqu'elle est déployée à partir de Git.

Se trouve mon .gitignore excluait le dossier build de ..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props.

Une fois que le dossier build a été (force) validé sur Git, le problème a été résolu.

Pour moi, mon fichier gitignore ignorait mon dossier packages. La ligne gitignore suivante causait le problème -

**/packages/*

Supprimé et restauré mon dossier packages. Espérons que cela aide quelqu'un d'autre.