J'ai cherché ce problème mais aucune des solutions n'a fonctionné. J'ai Visual Studio Professional 2015 installé et j'utilise TFS. Ma version NuGet est 3.1.6. Ce problème se produit uniquement dans mon projet C # Web API / MVC.

J'obtiens l'erreur ci-dessous:

Ce projet fait référence aux packages NuGet manquants sur cet ordinateur. Utilisez NuGet Package Restore pour les télécharger. Pour plus d'informations, voir http://go.microsoft.com/fwlink/?LinkID=322105 . Le fichier manquant est .. \ packages \ Microsoft.Net.Compilers.1.0.0 \ build \ Microsoft.Net.Compilers.props

1. Je n'ai pas de dossier .nuget dans mes solutions.
2. J'ai un dossier de packages 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.
3. J'ai essayé de supprimer le projet de TFS et cela n'a pas été résolu.
4. Parallèlement à l'erreur ci-dessus, toutes les références du projet ont des panneaux d'avertissement jaunes et indiquent qu'elles sont manquantes.
5. Lorsque j'ai vérifié le gestionnaire de packages NuGet pour le projet, tout ce qui est "manquant" a une coche verte à côté, y compris Microsoft.Net.Compilers.
6. J'ai essayé d'ajouter un nouveau projet Web API / MVC et il a rencontré un problème similaire où la plupart des références telles que Owin étaient "manquantes" avec le panneau d'avertissement jaune.

J'ai eu la même erreur (il manque exactement le même paquet) aujourd'hui. J'ai également créé un projet d'API Web MVC +.

Cela s'est produit parce que j'ai déplacé les fichiers d'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 désormais (Visual Studio 2015) stockées dans le fichier .csproj.

La modification du fichier .csproj et la correction du chemin d'accès relatif au dossier de la solution (qui contient le dossier des packages) a résolu le problème pour moi.

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

<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 - cela met à jour les packages pour la solution entière et pas seulement pour le projet.

Si vous avez un autre paquet nuget manquant qui donnant votre erreur lors de la construction de votre solution, utilisez la commande suivante à l'aide de la console de commande Nuget dans Outils> Nuget Package Manager> Package Manager Console. Il réinstallera tous vos packages actuels.

Update-Package –reinstall

Mettre à jour:

Vous pouvez passer un nom de projet spécifique en tant que paramètre.

Update-Package –reinstall -ProjectName SampleApp

J'ai eu ce message frustrant exact. Ce qui a finalement fonctionné pour moi a été de supprimer tous les fichiers et dossiers dans / packages et de laisser VS récupérer tout le prochain build.

Tiberiu a raison. 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 dossier 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'))" />

cette façon a résolu mon erreur: Pour ouvrir le fichier .csproj pour la mise à jour dans Visual Studio 2015+ Solution Explorer:

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, créez votre solution.

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>

puis a fait

Update-Package -Reinstall

de la et cela a fonctionné.

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é. Remarque: Ce même dossier était dans notre contrôle de source mais pas dans ce projet de solutions, c'était un répertoire.

Activez simplement NuGet Package Restore. Cliquez avec le bouton droit sur votre solution> choisissez «Activer la restauration du package NuGet».

Cela créera le dossier .nuget avec le fichier NuGet.Config et corrigera mon problème.

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 aucune erreur.

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

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 .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 faisait uniquement référence à 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.

Pour tous ceux qui rencontrent ici le problème que j'ai rencontré (certains mais pas tous les packages sont restaurés sur un serveur de build), la dernière pièce du puzzle pour moi était d'ajouter un NuGet.config à la racine de ma solution, frère du .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 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>

METTRE À JOUR:

L'URL de l'API NuGet a changé pour la v3 (à jour en septembre 2016). Depuis 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é toutes les astuces et aucune n'a fonctionné. Le projet (test MVC Web App simple) est passé de la communauté Windows 8.1 VS 2015 à ma nouvelle boîte de test sous Windows 10. Toutes les dernières mises à jour de VS 2015 ont été appliquées. Je n'ai même pas pu installer de version plus récente du paquetage des 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 packages vers une version plus récente. Cela ressemble à un bug du processus de mise à niveau du projet nuget 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.

Solution qui fonctionne dans mon cas - Visual Studio 2015 Enterprice, projet .NET 4.6.1

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

Pour moi, les packages étaient là sous le bon chemin, mais pas les dossiers de construction à l'intérieur du dossier du package. J'ai simplement supprimé tous les packages qui manquaient et reconstruit la solution et il a réussi à créer les dossiers de construction et les fichiers .props. Les messages d'erreur étaient donc corrects en m'informant que quelque chose manquait.

J'ai eu ce problème en tant que build échoué dans Azure, lors du déploiement à partir de Git.

Il s'avère que mon .gitignore excluait le builddossier de ..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props.

Une fois que le builddossier a été (forcé) envoyé à Git, le problème a été résolu.

J'ai résolu le même problème avec les étapes suivantes

1. Package supprimé <package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="2.0.1" targetFramework="net46" />du fichier package.config.

2. Modifiez le fichier de projet .csproj et supprimez les paramètres ci-dessous. <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.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.1\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />   </Target>

   3. Accédez à la console du gestionnaire de packages et exécutez la commande Update-Package –reinstall

Les points # 2 et 3 ont été donnés par d'autres utilisateurs et j'apprécie ces utilisateurs. Point # 1, la suppression Microsoft.CodeDom.Providers.DotNetCompilerPlatformdu fichier package.config est plus importante. De plus, après avoir exécuté la commande mentionnée au point # 3, le problème a été résolu. Tous les packages indésirables supprimés et la référence de package requise mise à jour.

J'espère que cela aide quelqu'un.

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 build dans le chemin du script Pre-Build

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

Vous pouvez également utiliser le message d'erreur suggéré comme indice. Voici comment, recherchez les packages de gestion de solution, et cliquez sur le package de nuget manquant pour résoudre.

C'est tout

Commentez l'option de compilation 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 packages dans le fichier de configuration des packages

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

Reconstruisez si tout va bien, pas besoin de continuer, sinon Cliquez avec le bouton droit sur le projet, cliquez sur «décharger le projet» Cliquez de nouveau avec le bouton droit sur le projet et modifiez le fichier .csproj

Validez le chemin de Codedom, il n'y avait pas net45 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')" />

Comme beaucoup l'ont suggéré, la suppression de la <Target>balise peut la rendre compilable. Cependant, 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 MSTest.TestAdapterpaquet nuget lors de la compilation. Résolution de ce problème en supprimant la <Target>balise. Bien que la construction ait réussi, les méthodes de test sont devenues non détectables. L'explorateur de tests ne répertoriera pas les méthodes de test dans ce projet et Exécuter le test ou le test de débogage ne fonctionnera pas aussi bien.

Je l'ai rencontré lors de l'utilisation Visual Studio 2017et .Net framework 4.7cela peut très bien se produire dans d'autres versions

Le problème pour moi était que NuGet ne pouvait pas obtenir / mettre à jour automatiquement les packages car le chemin complet du fichier serait trop volumineux. Résolu en déplaçant ma solution vers un dossier dans mes documents au lieu d'un dossier profondément imbriqué .

Ensuite, vous pouvez 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 le 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 vers la dernière version.

Il s'agissait d'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 nuget restoresur le SLN affecté, ou projeter 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 de génération dans Visual Studio ou autonome. Si c'est le dernier, assurez-vous qu'il est dans PATH et ignorez l'étape 2.
2. Ouvrez la console VS Dev CMD 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
   VS2017call "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\VsDevCmd.bat"
3. call nuget restore MyStuff.SLNou call nuget restore MyStuff.csprojs'il n'y a pas de SLN.

Je ne sais pas si cela aidera quelqu'un, mais j'ai eu ce problème 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 j'archivais le projet dans l'Explorateur de solutions, mais j'ai oublié de toujours archiver la solution elle-même.) Quand j'avais besoin de retravailler, tout ce que j'avais dans TFS était le fichier .csproj, pas de fichier .sln. Donc, dans VS, j'ai fait un fichier -> Contrôle de source -> Avancé - Ouvrir à partir du serveur et ouvert le fichier .csproj. À partir de là, j'ai fait tout enregistrer 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 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 pour qu'il " s au même niveau que le dossier du projet. Tous mes chemins se sont résolus et j'ai pu le reconstruire.

Pour moi, mon fichier gitignore ignorait mon dossier de packages. La ligne gitignore suivante était à l'origine du problème -

**/packages/*

Supprimé et il a restauré mon dossier de packages. J'espère que ceci aide quelqu'un d'autre.

J'ai eu un correctif autour de cette erreur, en fait j'avais une version différente de MSTest.TestAdapter (1.3.2) dans mon dossier de packages et dans les références de fichiers .csproj pointaient vers MSTest.TestAdapter (1.1.0). J'ai remplacé tous les MSTest.TestAdapter (1.1.0) par MSTest.TestAdapter (1.3.2), et cela a résolu mon problème.

Je me rends compte que cette question est ancienne, mais je suis tombé sur la même situation aujourd'hui et je voulais jeter mes 2 cents pour toute personne ayant récemment trouvé ce problème. Un projet ASP MVC que j'avais déplacé manuellement vers un sous-dossier dans ma solution, puis supprimé et réajouté à la solution, à l'aide de Visual Studio 2017, donnait l'erreur mentionnée. Déplacer les dossiers "lib" et "packages" à la racine du même sous-dossier que le projet MVC a résolu mon problème.

J'avais le même problème, il s'avère que l'un des projets auxquels je faisais référence se trouvait 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.