Ich habe dieses Problem gesucht, aber keine der Lösungen hat funktioniert. Ich habe Visual Studio Professional 2015 installiert und verwende TFS. Meine NuGet-Version ist 3.1.6. Dieses Problem tritt nur in meinem C # Web API / MVC-Projekt auf.
Ich erhalte die folgende Fehlermeldung:
Dieses Projekt verweist auf NuGet-Pakete, die auf diesem Computer fehlen. Verwenden Sie NuGet Package Restore, um sie herunterzuladen. Weitere Informationen finden Sie unter http://go.microsoft.com/fwlink/?LinkID=322105 . Die fehlende Datei lautet .. \ packages \ Microsoft.Net.Compilers.1.0.0 \ build \ Microsoft.Net.Compilers.props
- Ich habe keinen .nuget-Ordner in meinen Lösungen.
- Ich habe einen Paketordner in der Lösung und wenn ich ihn lösche, scheint NuGet die Abhängigkeiten neu zu erstellen, aber das Projekt hat immer noch den obigen Fehler.
- Ich habe versucht, das Projekt aus TFS zu entfernen, aber es wurde nicht behoben.
- Zusammen mit dem obigen Fehler haben alle Referenzen im Projekt gelbe Warnzeichen und sagen, dass sie fehlen.
- Als ich den NuGet Package Manager für das Projekt überprüfte, wurde neben allem, was "fehlt", ein grünes Häkchen angezeigt, einschließlich Microsoft.Net.Compilers.
- Ich habe versucht, ein neues Web-API / MVC-Projekt hinzuzufügen, und es gab ein ähnliches Problem, bei dem die meisten Referenzen wie Owin mit dem gelben Warnzeichen "fehlten".
visual-studio
nuget
visual-studio-2015
Fragen Tion
quelle
quelle
Antworten:
Ich hatte heute den gleichen Fehler (es fehlte genau das gleiche Paket). Ich habe auch ein MVC + Web API-Projekt erstellt.
Es passierte, weil ich die App-Dateien (einschließlich der .csproj) -Datei an einen anderen Speicherort verschoben habe. Ich habe die SLN-Datei manuell aktualisiert, aber alle Paketabhängigkeiten werden jetzt (Visual Studio 2015) in der CSsproj-Datei gespeichert.
Das Bearbeiten der .csproj-Datei und das Korrigieren des relativen Pfads zum Lösungsordner (der den Paketordner enthält) löste das Problem für mich.
quelle
Ich habe mein Problem gelöst, indem ich diesen Code aus der
.csproj
Datei entfernt habe:quelle
ACHTUNG - Hiermit werden Pakete für die gesamte Lösung aktualisiert, nicht nur für das Projekt.
Wenn Sie ein weiteres fehlendes Nuget-Paket haben, das beim Erstellen Ihrer Lösung einen Fehler verursacht, verwenden Sie den folgenden Befehl mit der Nuget-Befehlskonsole unter Extras> Nuget-Paketmanager> Paketmanager-Konsole. Alle aktuellen Pakete werden neu installiert.
Aktualisieren:
Sie können einen bestimmten Projektnamen als Parameter übergeben.
quelle
Ich hatte genau diese frustrierende Nachricht. Was schließlich für mich funktioniert hat, war, alle Dateien und Ordner in / packages zu löschen und VS beim nächsten Build alles erneut abrufen zu lassen.
quelle
Restore Nuget Packages
.Tiberiu ist richtig. Ich musste meine .csproj-Datei bearbeiten, als die Dateien verschoben wurden und dieses Problem verursachten
Ich habe oben in der Datei und unten geändert
quelle
Auf diese Weise wurde mein Fehler behoben: So öffnen Sie die .csproj-Datei zur Aktualisierung in Visual Studio 2015+ Solution Explorer:
Klicken Sie mit der rechten Maustaste auf Projektname -> Projekt entladen
Klicken Sie mit der rechten Maustaste auf den Projektnamen -> Bearbeiten Sie .csproj
Entfernen Sie die folgenden Zeilen:
Klicken Sie mit der rechten Maustaste auf Projektname -> Projekt neu laden
Erstellen Sie endlich Ihre Lösung.
quelle
Ich habe dieses Problem gelöst, indem ich den folgenden Code aus der .csproj-Datei entfernt habe
quelle
Eine Kombination der beiden Antworten hat bei mir funktioniert. Zuerst habe ich die .csproj-Datei geändert, um den Verweis auf die Version 1.0.0 zu entfernen
und dann tat
von der und es hat funktioniert.
quelle
Für mich bestand das Problem darin, dass beim Kopieren der Lösung in einen neuen Ordner und Öffnen des Nuget-Ordners der unten gezeigte Ordner fehlte. Ich habe diesen Ordner kopiert und alles hat funktioniert. Hinweis: Dieser Ordner befand sich in unserer Quellcodeverwaltung, jedoch nicht in diesem Lösungsprojekt. Er befand sich in einem Verzeichnis.
quelle
Aktivieren Sie einfach die NuGet-Paketwiederherstellung. Klicken Sie mit der rechten Maustaste auf Ihre Lösung und wählen Sie "NuGet-Paketwiederherstellung aktivieren".
Dadurch wird der Ordner .nuget mit der Datei NuGet.Config erstellt und mein Problem behoben.
quelle
Ich verwende VS2012 und habe den gleichen Fehler. Ich habe das folgende Target-Tag aus der .csproj-Datei entfernt und es wurde ohne Fehler kompiliert.
quelle
Um einige der Antworten hier zu erweitern, können Sie den folgenden Block aus Ihrer .csproj-Datei entfernen:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
Dies behebt das Problem. In meinem Fall habe ich jedoch festgestellt, dass ich zusätzliche Verweise auf die .NET.Compiler und .CodeDom.Provider mit unterschiedlichen Versionen hatte:
Wenn meine packages.config nur auf Folgendes verwies:
Das Entfernen der 1.0.0-Elemente aus der .csproj-Datei hat das Problem behoben.
quelle
Für alle, die hier über das Problem stolpern, das ich hatte (einige, aber nicht alle Pakete werden auf einem Build-Server wiederhergestellt), bestand das letzte Puzzleteil für mich darin, eine NuGet.config im Stammverzeichnis meiner Lösung hinzuzufügen, die der .SLN als Geschwister dient Datei, wie David Ebbo hier erklärte: http://blog.davidebbo.com/2014/01/the-right-way-to-restore-nuget-packages.html .
Aus Ebbos Blog-Post geht hervor, dass der Dateiinhalt für mich einfach ist
AKTUALISIEREN:
Die NuGet-API-URL wurde für Version 3 geändert (Stand: September 2016). Von https://www.nuget.org/
quelle
Die Fehlermeldung ist vollständig korrekt. Ich habe alle Tricks ausprobiert und keiner hat funktioniert. Das Projekt (einfacher MVC Web App-Test) wurde von Windows 8.1 VS 2015 Community auf meine neue Testbox unter Windows 10 verschoben. Es wurden alle neuesten Updates für VS 2015 angewendet. Ich konnte nicht einmal eine neuere Version des Compiler-Pakets installieren.
Ich habe schließlich gerade Microsoft.Net.Compilers.1.0.0 vom alten Projekt in das neue kopiert und es hat funktioniert. Ich könnte dann anfangen, andere Pakete auf eine neuere Version zu aktualisieren. Sieht für mich nach einem Fehler beim Upgrade des Nuget-Projekts aus.
HINWEIS: Das ursprüngliche Projekt wurde in VS 2015 erstellt und verfügt über keine älteren Nuget-Methoden.
quelle
Lösung, die in meinem Fall funktioniert - Visual Studio 2015 Enterprice, Projekt .NET 4.6.1
quelle
Für mich befanden sich die Pakete unter dem richtigen Pfad, die Build-Ordner im Paketordner jedoch nicht. Ich habe einfach alle fehlenden Pakete entfernt und die Lösung neu erstellt und die Build-Ordner und die .props-Dateien erfolgreich erstellt. Die Fehlermeldungen haben mich also korrekt darüber informiert, dass etwas fehlgeschlagen ist.
quelle
Ich hatte dieses Problem als fehlgeschlagenes Build in Azure, als es von Git bereitgestellt wurde.
Es stellte sich heraus, dass mein .gitignore den
build
Ordner von ausgeschlossen hat..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props
.Sobald der
build
Ordner für Git festgeschrieben wurde, wurde das Problem behoben.quelle
Ich habe das gleiche Problem mit den folgenden Schritten gelöst
<package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="2.0.1" targetFramework="net46" />
aus der Datei package.config entfernt.Bearbeiten Sie die .csproj-Projektdatei und entfernen Sie die folgenden Einstellungen.
<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>
Update-Package –reinstall
Punkt 2 und 3 wurden von anderen Benutzern gegeben und ich schätze diese Benutzer. Punkt 1, das Entfernen der
Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Datei package.config ist wichtiger. Nachdem der in Punkt 3 genannte Befehl ausgeführt wurde, wurde das Problem behoben. Alle unerwünschten Pakete wurden entfernt und die erforderliche Paketreferenz aktualisiert.Hoffe das hilft jemandem.
quelle
Ich konnte keine Lösung dafür finden und fügte dem Stammverzeichnis der Lösung namens prebuild.ps1 eine Kopie der Datei nuget.exe und ein Powershell-Skript mit dem folgenden Inhalt hinzu.
Ich habe dieses Powershell-Skript in meinem Build im Pre-Build- Skriptpfad aufgerufen
quelle
Meins funktionierte, als ich den Paketordner zusammen mit der Lösungsdatei und dem Projektordner kopierte. Ich habe den Paketordner einfach nicht vom vorherigen Ort kopiert.
quelle
Sie können die vorgeschlagene Fehlermeldung auch als Hinweis verwenden. Hier erfahren Sie, wie Sie die Pakete für Lösung verwalten suchen und auf das fehlende Nuget-Paket zum Auflösen klicken.
Das ist es
quelle
Kommentieren Sie die Compiler-Option in
WebConfig
:Neu erstellen, wenn alles in Ordnung ist, Sie müssen nicht fortfahren. Andernfalls klicken Sie mit der rechten Maustaste auf das Projekt, klicken Sie auf "Projekt entladen". Klicken Sie erneut mit der rechten Maustaste auf das Projekt und bearbeiten Sie die .csproj-Datei
Überprüfen Sie den Pfad von Codedom, da in vorherigen Pfaden kein net45 vorhanden war. Fügen Sie diesen manuell hinzu, speichern, laden und neu erstellen. Es sollte funktionieren.
quelle
Wie viele vorgeschlagen haben,
<Target>
kann das Entfernen des Tags kompilierbar sein. Beachten Sie jedoch, dass dies einen Nebeneffekt hat, wenn Sie dies für Testprojekte tun.MSTest.TestAdapter
Beim Kompilieren ist ein Fehler im Zusammenhang mit dem Nuget-Paket aufgetreten. Dieses Problem wurde durch Entfernen des<Target>
Tags behoben. Obwohl der Build erfolgreich war, konnten die Testmethoden nicht mehr entdeckt werden. Der Test Explorer listet die Testmethoden in diesem Projekt nicht auf und Run Test oder Debug Test funktionieren ebenfalls nicht.Ich habe dies während der Verwendung festgestellt
Visual Studio 2017
und.Net framework 4.7
es kann sehr gut in anderen Versionen passierenquelle
$(SolutionDir)
Arbeit ersetzen , aber Aktualisierung schlägt fehl. Ich fragte , dass hier . Haben Sie eine Lösung gefunden?Das Problem für mich war, dass NuGet die Pakete nicht automatisch abrufen / aktualisieren konnte, da der vollständige Dateipfad zu groß wäre. Behoben durch Verschieben meiner Lösung in einen Ordner in meinen Dokumenten anstelle eines tief verschachtelten Ordners .
Klicken Sie dann mit der rechten Maustaste auf die Lösung und wählen Sie "NuGet-Pakete wiederherstellen" (was wahrscheinlich nicht erforderlich ist, wenn Sie es nur erstellen und für Sie erledigen lassen). Wählen Sie dann "NuGet-Pakete für Lösung verwalten", um alle Pakete abzurufen auf die neueste Version aktualisiert.
Dies war eine Lösung für eine ASP MVC-Beispielanwendung, die von der Microsoft-Website heruntergeladen wurde.
quelle
Für DevOps / Build-Ingenieure können Sie dieses
nuget restore
Problem wahrscheinlich beheben , wenn es für das betroffene SLN ausgeführt wird, oder für ein Projekt, wenn Ihnen ein SLN fehlt. Ich muss dies für unsere CI / CD-Builds für alle unsere UWP-Projekte tun.VS2015
call "%VS140COMNTOOLS%VsDevCmd.bat"
oder
VS2017
call "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\VsDevCmd.bat"
call nuget restore MyStuff.SLN
odercall nuget restore MyStuff.csproj
wenn es keine SLN gibt.quelle
Ich bin mir nicht sicher, ob dies jemandem helfen wird, aber dieses Problem trat auf, als ich den Quellcode von meinem lokalen Computer löschte, ohne die Lösungsdatei jemals in TFS gespeichert zu haben. (Während der ersten Entwicklung habe ich mit der rechten Maustaste auf das Projekt im Projektmappen-Explorer geklickt und es eingecheckt, aber vergessen, jemals die Lösung selbst einzuchecken.) Als ich erneut daran arbeiten musste, war alles, was ich in TFS hatte, die .csproj-Datei. keine .sln-Datei. Also habe ich in VS eine Datei -> Quellcodeverwaltung -> Erweitert - Vom Server öffnen und die .csproj-Datei geöffnet. Von dort aus habe ich alles gespeichert und gefragt, wo ich die SLN-Datei speichern möchte. Ich habe diese SLN-Datei mit den anderen Ordnern (App_Data, App_Start usw.) im Projektverzeichnis gespeichert, nicht mit dem Verzeichnis der obersten Ebene. Ich habe endlich herausgefunden, dass ich die SLN-Datei in einem Verzeichnis aus dem Projektordner speichern muss, damit es s auf derselben Ebene wie der Projektordner. Alle meine Wege lösten sich auf und ich konnte es wieder aufbauen.
quelle
Für mich ignorierte meine Gitignore-Datei meinen Paketordner. Die folgende Gitignore-Zeile verursachte das Problem -
Entfernt und mein Paketordner wiederhergestellt. Hoffe das hilft jemand anderem.
quelle
Ich habe eine Korrektur für diesen Fehler erhalten. Tatsächlich hatte ich eine andere Version von MSTest.TestAdapter (1.3.2) in meinem Paketordner und in .csproj-Dateiverweisen wurde auf MSTest.TestAdapter (1.1.0) verwiesen. Ich habe alle MSTest.TestAdapter (1.1.0) durch MSTest.TestAdapter (1.3.2) ersetzt, und dies hat mein Problem behoben.
quelle
Mir ist klar, dass diese Frage alt ist, aber ich bin heute in die gleiche Situation geraten und wollte meine 2 Cent für jeden einwerfen, der dieses Problem kürzlich entdeckt hat. Ein ASP MVC-Projekt, das ich manuell in einen Unterordner in meiner Lösung verschoben und dann mit Visual Studio 2017 entfernt und erneut in die Lösung eingelesen hatte, gab den genannten Fehler aus. Das Verschieben der Ordner "lib" und "packages" in das Stammverzeichnis desselben Unterordners wie das MVC-Projekt hat mein Problem behoben.
quelle
Ich hatte das gleiche Problem. Es stellte sich heraus, dass sich eines der Projekte, auf die ich verwies, außerhalb des Lösungsverzeichnisses befand (und daher nicht denselben Ordner '/ packages' freigegeben hat). Die Lösung, die für mich funktioniert hat, bestand darin, die Lösung des Referenzprojekts zu öffnen und dort zu erstellen. Sobald dieses Projekt erstellt wurde, verschwanden die Fehler.
quelle