Les paquets NuGet sont manquants
J'ai cherché ce problème mais aucune des solutions n'a fonctionné. Visual Studio Professional 2015 est installé et j'utilise TFS. Ma version de NuGet est 3.1.6. Ce problème ne se produit que dans mon projet API Web/MVC C #.
Je reçois l'erreur ci-dessous:
Ce projet fait référence aux packages NuGet manquants dans ce fichier ordinateur. Utilisez NuGet Package Restore pour les télécharger. Pour plus informations, voir http://go.Microsoft.com/fwlink/?LinkID=322105 . Le le fichier manquant est ..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props
- Je n'ai pas de dossier .nuget dans mes solutions.
- J'ai un dossier de paquets dans la solution et quand je le supprime, il semble que NuGet reconstruise les dépendances mais le projet a toujours l'erreur ci-dessus.
- J'ai essayé de supprimer le projet de TFS et cela n'a pas résolu le problème.
- En plus de l'erreur ci-dessus, toutes les références du projet comportent des panneaux d'avertissement jaunes indiquant qu'ils sont absents.
- Lorsque j'ai vérifié le gestionnaire de paquets NuGet pour le projet, tous les éléments "manquants" sont cochés en vert, y compris Microsoft.Net.Compilers.
- J'ai essayé d'ajouter un nouveau projet Web API/MVC et le problème était similaire: la plupart des références telles que Owin "manquaient" avec le panneau d'avertissement jaune.
J'ai eu la même erreur (manquant exactement le même paquet) aujourd'hui. J'ai également créé un projet API Web MVC +.
C'est arrivé parce que j'ai déplacé les fichiers de l'application (y compris le fichier .csproj) vers un autre emplacement. J'ai mis à jour manuellement le fichier .sln mais toutes les dépendances des packages sont maintenant (Visual Studio 2015) stockées dans un fichier .csproj.
La modification du fichier .csproj et la correction du chemin relatif du dossier solution (qui contient le dossier packages) ont résolu le problème.
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>
ATTENTION - ceci met à jour les paquets pour la solution entière et pas seulement pour le projet.
Si vous avez un autre paquet de nuget manquant qui donne votre erreur lors de la création de votre solution, utilisez la commande suivante en utilisant Nuget Command Console dans Outils> Nuget Package Manager> Package Manager Console. Il réinstallera tous vos paquets actuels.
Package de mise à jour –reinstall
J'ai eu ce message frustrant exact. Ce qui a finalement fonctionné pour moi a été de supprimer tous les fichiers et dossiers de/packages et de laisser les VS récupérer à nouveau toutes les données de la prochaine construction.
Tibériu est correct. J'ai dû modifier mon fichier .csproj car les fichiers ont été déplacés et ont 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é en haut 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 du 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. J'ai d'abord modifié le fichier .csproj pour supprimer la référence à la version 1.0.0
< Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild" >
----Error---
< /Target>
et ensuite
Update-Package -Reinstall
de la et cela a fonctionné.
Activez simplement la restauration du paquet NuGet. Cliquez avec le bouton droit de la souris sur votre solution> choisissez "Activer la restauration du paquet NuGet".
Cela créera le dossier .nuget avec le fichier NuGet.Config et corrigera mon problème.
Pour moi, le problème était que lorsque j'ai copié la solution dans un nouveau dossier et que je l'ai ouvert, il manquait le dossier Nuget, comme indiqué ci-dessous. J'ai copié ce dossier et tout a fonctionné. Remarque: Ce même dossier se trouvait dans notre contrôle de code source, mais pas dans ce projet de solutions, mais dans un répertoire.
J'utilise VS2012 et je fais face à la même erreur. J'ai supprimé la balise Target suivante du fichier .csproj et la compilation a commencé sans erreur.
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
-- Error messages within Target Tag
</Target>
Pour développer quelques réponses, vous pouvez supprimer le bloc suivant de votre fichier .csproj:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
et cela corrige le problème, mais dans mon cas, j'ai remarqué que j'avais des références supplémentaires aux .NET.Compilers et .CodeDom.Providers 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\
Lorsque mon packages.config ne mentionnait que ce qui suit:
<package id="Microsoft.Net.Compilers" version="2.0.1"
<package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.3"
La suppression des éléments 1.0.0 du fichier .csproj a résolu le problème.
cette façon a résolu mon erreur: Pour ouvrir le fichier .csproj à mettre à jour dans l'explorateur de solutions Visual Studio 2015+:
Cliquez avec le bouton droit sur le nom du projet -> Décharger le projet
Cliquez avec le bouton droit sur le nom du projet -> Modifier .csproj
Supprimez les lignes suivantes:
<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('..\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.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
<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.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', 'packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
</Target>
Cliquez avec le bouton droit sur le nom du projet -> Recharger le projet
Enfin, construisez votre solution.
Pour ceux qui trébuchent ici avec le problème que j'ai rencontré (certains paquets, mais pas tous, étant restaurés sur un serveur de compilation), la dernière pièce du puzzle consistait pour moi à ajouter un NuGet.config à la racine de ma solution, associé au .SLN fichier comme David Ebbo a expliqué ici: http://blog.davidebbo.com/2014/01/the-right-way-to-restore-nuget-packages.html .
D'après le blog d'Ebbo, le contenu de mon fichier est simplement:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://www.nuget.org/api/v2/" />
</packageSources>
</configuration>
METTRE À JOUR:
L'URL de l'API NuGet a changé pour la v3 (mise à jour en septembre 2016). 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 (test MVC Web App simple) est passé de Windows 8.1 VS 2015 Community à ma nouvelle boîte de test sous Windows 10. Toutes les dernières mises à jour de VS 2015 ont été appliquées . Je ne pouvais même pas installer une version plus récente du package des compilateurs.
Loop:
<LOOP>This seems to be a Ground Hog Day phenomena.</LOOP>
GoTo Loop
J'ai finalement finalement copié Microsoft.Net.Compilers.1.0.0 de l'ancien projet dans le nouveau et tout a fonctionné ... Je pourrais alors commencer à mettre à jour les autres packages vers une version plus récente . Cela ressemble à un processus de mise à niveau d'un projet Nuget bug pour moi.
REMARQUE: Le projet d'origine a été créé dans VS 2015 et ne possède aucune méthodologie de nuget héritée.
Pour moi, les paquets étaient là sous le chemin correct, mais les dossiers de construction à l'intérieur du dossier des paquets ne l'étaient pas. J'ai simplement supprimé tous les paquetages manquants, reconstruit la solution et créé avec succès les dossiers de construction et les fichiers .props. Donc, les messages d'erreur m'indiquaient que quelque chose manquait.
J'avais ce problème en tant que version ayant échoué dans Azure lors du déploiement de Git.
Il se trouve que 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é (forcé) envoyé à Git, le problème a été résolu.
J'ai eu un correctif autour de cette erreur, j'avais en fait une version différente de MSTest.TestAdapter (1.3.2) dans mon dossier packages et les références de fichier .csproj pointaient vers MSTest.TestAdapter (1.1.0). J'ai remplacé tous les MSTest.TestAdapter (1.1.0) par MSTest.TestAdapter (1.3.2), ce qui a résolu mon problème.
Pour moi, mon fichier gitignore ignorait mon dossier packages. La ligne suivante de gitignore était à l’origine du problème -
**/packages/*
Supprimé et restauré mon dossier de paquets. J'espère que ceci aide quelqu'un d'autre.
Le problème pour moi était que NuGet ne pouvait pas obtenir/mettre à jour automatiquement les paquetages car le chemin d'accès au fichier complet serait trop grand. Résolu en déplaçant ma solution dans un dossier de mes documents au lieu d’un dossier profondément imbriqué .
Vous pouvez ensuite cliquer avec le bouton droit sur la solution et sélectionner "Restaurer les packages NuGet" (ce qui n'est probablement pas nécessaire si vous la construisez et le laissez le faire pour vous), puis sélectionnez "Gérer les packages NuGet pour la solution" pour obtenir tous les packages. mis à jour à la dernière version.
Il s'agissait d'une solution d'un exemple d'application ASP MVC téléchargée depuis le site Web de Microsoft.
J'avais le même problème, il s'est avéré qu'un des projets que je faisais référence était en dehors du répertoire de la solution (et ne partageait donc pas le même dossier '/ packages'). La solution qui a fonctionné pour moi a été d'ouvrir la solution du projet de référence et de la construire là-bas. Une fois ce projet construit, les erreurs ont disparu.
Dans mon cas, il manquait <RestorePackages>true</RestorePackages> dans le fichier * .csproj. Il n'était pas nécessaire de supprimer des extraits de code que je vois dans les réponses précédentes.
n nom d'utilisateur différent en est la cause habituelle, Nuget télécharge tout dans: "C:\Users\USER_NAME\source\repos" et si le projet avait déjà été configuré sous un nom d'utilisateur différent, le fichier .csproj peut toujours contenir cet ancien fichier. nom d’utilisateur ici, ouvrez-le simplement et effectuez une recherche, remplacez "C:\Users\_OLD_USER_NAME\source\repos" par "C:\Users\NEW_USER_NAME\source\repos".
Comme beaucoup l'ont suggéré, supprimer la balise <Target> peut le rendre compilable. Cependant, méfiez-vous du fait que cela a un effet secondaire lorsque vous le faites pour des projets tests.
J'ai eu une erreur liée au paquet de nuget MSTest.TestAdapter lors de la compilation. Résolu ce problème en supprimant la balise <Target>. Bien que cela ait rendu la construction réussie, les méthodes de test sont devenues non découvrables. Test Explorer ne listera pas les méthodes de test de ce projet et Run Test ou Debug Test ne fonctionnera pas aussi bien.
J'ai rencontré ceci en utilisant Visual Studio 2017 et .Net framework 4.7, cela peut très bien arriver dans d'autres versions
Je me rends compte que cette question est ancienne, mais j’ai rencontré la même situation aujourd’hui et je voulais apporter mes 2 centimes à toute personne ayant récemment découvert ce problème. Un projet ASP MVC que j'avais déplacé manuellement dans un sous-dossier de ma solution, puis supprimé et lu dans la solution, à l'aide de Visual Studio 2017, renvoyait l'erreur mentionnée. Déplacer les dossiers "lib" et "packages" vers la racine du même sous-dossier que le projet MVC a résolu mon problème.
Vous pouvez également utiliser le message d'erreur suggéré comme indice. Voici comment trouver la solution Gérer les packages pour la solution, puis cliquez sur le package de résolution de nuget manquant.
C'est tout
Le dossier dans ma solution s'appelait "Projet .NET". En le renommant "NET Project", tout a bien fonctionné. Donc, le point au début était une mauvaise idée.
N'ayant trouvé aucune solution à ce problème, j'ai ajouté une copie du fichier nuget.exe et un script PowerShell au répertoire racine de la solution, 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 de script Pre-Build 
Le mien a fonctionné lorsque j'ai copié le dossier des packages avec le fichier solution et le dossier du projet. Je viens de ne pas copier le dossier des paquets de la place précédente.
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=\"Web\" /optionInfer+" />
</compilers>
</system.codedom>-->
Mettre à jour la dernière version des packages dans le fichier de configuration du package
<package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.4" targetFramework="net452" />
Reconstruisez si tout est ok, pas besoin de continuer, sinon Cliquez avec le bouton droit de la souris sur le projet, cliquez sur "Décharger le projet" Cliquez à nouveau avec le bouton droit de la souris sur le projet et modifiez le fichier .csproj.
Validez le chemin de Codedom, net45 ne figurait pas dans les chemins précédents, ajoutez-le manuellement, enregistrez, chargez, reconstruisez. Ça devrait marcher.
<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')" />
Je ne suis pas sûr que cela puisse aider quelqu'un, mais ce problème s'est posé lorsque j'ai supprimé le code source de mon ordinateur local sans avoir jamais enregistré le fichier de solution dans TFS. (Lors du développement initial, j’étais en train de cliquer avec le bouton droit de la souris et d’archiver le projet dans Solution Explorer, mais j’avais oublié de l’archiver elle-même.) Lorsque j’avais besoin de retravailler cela, je n’avais que le fichier .csproj, aucun fichier .sln. Ainsi, dans VS, j'ai créé un fichier -> Contrôle de la source -> Avancé - Ouvrir depuis le serveur et ouvrir le fichier .csproj. À partir de là, j'ai fait une sauvegarde de tous les fichiers et il m’a demandé où je voulais enregistrer le fichier .sln. J'enregistrais ce fichier .sln dans le répertoire du projet avec les autres dossiers (App_Data, App_Start, etc.), pas dans le répertoire de niveau supérieur. J'ai finalement compris que je devais enregistrer le fichier .sln dans un répertoire du dossier du projet afin qu'il se trouve au même niveau que le dossier du projet. Tous mes chemins se sont résolus et j'ai pu le reconstruire.
Pour les ingénieurs DevOps/build, vous pouvez probablement résoudre ce nuget restore en cours d’exécution sur le SLN affecté ou sur un projet s’il manque un SLN. Je dois le faire pour nos constructions CI/CD pour tous nos projets UWP.
- Assurez-vous que nuget est installé sur l'esclave de construction dans Visual Studio ou en mode autonome. Si c'est le dernier cas, assurez-vous qu'il est dans PATH et ignorez l'étape 2.
- Ouvrez la console VS Dev CMD ou chargez-la via une console déjà ouverte, comme vous pouvez le faire avec les instructions ci-dessous:
VS2015call "%VS140COMNTOOLS%VsDevCmd.bat"
ou
VS2017call "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\VsDevCmd.bat" call nuget restore MyStuff.SLNoucall nuget restore MyStuff.csprojs'il n'y a pas de SLN.