VS 15.8.2 hat Build-Tools kaputt gemacht - RuntimeIdentifier fehlt

Das letzte Windows-Update hat unsere gesamte Build-Kette unterbrochen, und ich bin ein wenig ratlos darüber, was es verursacht.

Ich habe ein Legacy-Projekt, bei dem es sich um eine VS 2017-Lösung mit einer erheblichen Anzahl von Projekten handelt (Winform, paarweise webbasiert, einige nur Webapi).

Vor Ort funktionieren die Dinge perfekt. Ich kann sie einfach bauen.

Auf dem Server ist das Projekt fehlgeschlagen. Der Fehler lautet:

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.

Process 'msbuild.exe' exited with code '1'.

Ich habe hinzugefügt

<RuntimeIdentifiers>win</RuntimeIdentifiers>

Zu einer Reihe von Projekten. Keine Änderung. Ich bin ratlos, weil die Fehlermeldung mir nicht einmal sagt, welches Projekt.

Irgendwann, bevor Sie versuchen zu erstellen, müssen Sie den Ordner obj löschen. Mehr als eine Person hat dies gezeigt, um das Problem zu lösen.

https://developercommunity.visualstudio.com/content/problem/312180/projects-fail-to-build-in-1580-due-to-errors-from.html

Obwohl mir die Antwort von @ Señor CMasMas in der Vergangenheit geholfen hat, stelle ich jetzt (seit der Installation des .NET Core SDK v2.2 - keine Ahnung, ob dies verwandt ist) fest, dass ich Visual Studio auch schließen und erneut öffnen muss . Für mich lautet das Rezept also:

• Saubere Lösung
• objOrdner löschen
• Löschen Sie den .vsOrdner (optional, wenn Sie rote Linien erhalten, dieser aber in Ordnung ist)
• Schließen Sie Visual Studio und öffnen Sie es erneut
• Dann bauen

Fügen Sie Folgendes hinzu: <RuntimeIdentifier>win</RuntimeIdentifier> zu Ihrer Projektdatei, z. B. nach Element TargetFrameworkVersion. Stellen Sie sicher, dass der Elementname singulär ist. RuntimeIdentifierswird dagegen im neuen csproj-Format verwendet

Oder Sie können einfach im Stammverzeichnis Ihres Projekts das Skript in PowerShell ausführen, das Sie als Administrator ausführen sollten.

Get-ChildItem .\ -include bin,obj -Recurse | foreach { remove-item $_.fullname -Force -Recurse }

Dieses Skript löscht alle obj- und bin-Ordner

Sie müssen herausfinden, welche Projekte in Ihrer Lösung diesen Fehler auslösen. Sie finden dies, wenn Sie sich das Fehlerfeld ansehen. Gehen Sie zu den Speicherorten des Projekts und löschen Sie sowohl den Ordner bin als auch den Ordner obj. dann wieder aufbauen. sollte in Ordnung sein

Ich habe einen ähnlichen Fall. Ich versuche, eine Lösung über msbuild zu erstellen, ohne Visual Studio 2017 zu installieren. Installieren Sie einfach die neueste Version der Build-Tools von vs 2017. Hier sind meine Schritte:

1. dotnet restore a.sln (Diese Lösung enthält einige .NET Standard Library-Projekte, die anderen sind .NET 4.7.2-Projekte).
2. Rufen Sie msbuild.exe auf, um diese Lösung zu erstellen.
3. Ich habe den Fehler "RuntimeIdentifier fehlt" erhalten.

In Ihrer Projektdatei wird 'win' nicht als "RuntimeIdentifier" aufgeführt. Sie sollten der Eigenschaft "RuntimeIdentifiers" in Ihrer Projektdatei 'win' hinzufügen und dann die NuGet-Wiederherstellung erneut ausführen.

Es scheint ein Problem in der alten Version von Nuget zu sein. Bitte beziehen Sie sich hier . Schließlich habe ich es über Wiederherstellungspakete mit dem neuesten Nuget (v5.0.2) gelöst. die Schritte:

1. Löschen Sie die Ordner obj und bin
2. nuget.exe stellt a.sln wieder her
3. Rufen Sie msbuild.exe auf

Ich hatte ein ähnliches Problem. Mein Fehler war

Fehler: In Ihrer Projektdatei wird 'win10' nicht als "RuntimeIdentifier" aufgeführt. Sie sollten der Eigenschaft "RuntimeIdentifiers" in Ihrer Projektdatei 'win10' hinzufügen und dann die NuGet-Wiederherstellung erneut ausführen.

Nun, es stellte sich heraus, dass ich nur durch Erstellen eines Ziels von "Beliebige CPU" auf etwas anderes (zum Beispiel x64) wechseln musste ...

Der RuntimeIdentifier sollte ungefähr so ​​aussehen wie hier beschrieben: https://docs.microsoft.com/en-us/dotnet/core/rid-catalog .

Da dies nur lokal zu finden scheint, würde ich die .csproj auf Ihrem lokalen Computer von der auf Ihrem Build-Server unterscheiden. Etwas sagt mir, sie sind nicht identisch.

FWIW, Zeile 186 in der angegebenen Microsoft.NuGet.targets-Datei, führt die Task ResolveNuGetPackageAssets aus, und Sie können sehen, dass das Argument RuntimeIdentifier als NuGetRuntimeIdentifier-Eigenschaft übergeben wird. Sie können dies wahrscheinlich im Diagnoseprotokoll Ihres Arbeits-Builds zurückverfolgen, um zu sehen, wie es zugewiesen wird.

Da dies jedoch auf einer Box und nicht auf einer anderen funktioniert, würde ich nur Ihre Projektdateien überprüfen und sicherstellen, dass das RuntimeIdentifier-Tag auf beiden Systemen identisch ist.

Mit freundlichen Grüßen,

Ich hatte das gleiche Problem beim Umschalten zwischen vstools Build-Ketten (VS2017 / VS2019) - hier ist, was es für mich behoben hat - Brute Force Clean via rimraf

In Ihrer Projektdatei wird 'win' nicht als "RuntimeIdentifier" aufgeführt. Sie sollten der Eigenschaft "RuntimeIdentifiers" in Ihrer Projektdatei "win" hinzufügen und dann die NuGet-Wiederherstellung erneut ausführen

Entfernen Sie Intermediary Build Output-Artefakte

rimraf *\obj\**

Für mich war es so einfach wie das Kompilieren einer Windows IoT-App mit x86Plattform statt ARM.

In meinem Fall geschah dies bei einem Azure-Build.

Ich konnte das Problem beheben, indem ich den Build zwang, Visual Studio 2019-Tools zu verwenden.

Ich habe unsere Datei build.cake so geändert , dass die MSBuild-Schritte die UseToolVersion für VS 2019 wie folgt enthielten:

     MSBuild(_solutionFile, settings => settings.SetConfiguration(_configuration)
         .UseToolVersion(MSBuildToolVersion.VS2019));

Das einzige, was für mich funktioniert hat, war, ALLE Projektdateien zu löschen und sie erneut von der Versionskontrolle herunterzuladen. Dann verschwand das Problem.

Wenn Sie Azure Service - Stoff oder einem anderen 64-Bit - Umgebung sind Targeting sicherstellen , dass Sie eine konsistente haben <PlatformTarget>x64</PlatformTarget>in allen Konfigurationen in der Csproj - Datei definiert. In meinem Fall wurde es lokal einwandfrei erstellt, schlug jedoch auf dem CI-Server fehl, da eine der vielen Konfigurationen vorhanden war <PlatformTarget>AnyCPU</PlatformTarget>.

Ich habe den gleichen Fehler wie das Originalposter mit Msbuild v15.9.21 erhalten

Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore

Meine Projekte sind .net Framework v4.6.2. Die Projekte werden mit VS 2017 lokal problemlos erstellt, sind jedoch beim Erstellen auf TeamCity Enterprise 10.0.5 fehlgeschlagen. Ich habe kürzlich meine Projekte von .package in PackageReference konvertiert, wodurch der Build fehlschlug.

Meine Lösung bestand darin, einen neuen Erstellungsschritt hinzuzufügen, um die Nuget-Pakete der Lösung vor dem Erstellen der Lösung explizit wiederherzustellen. Es scheint, dass dies vor der Konvertierung der Projekte in PackageReference implizit im Build-Schritt durchgeführt wurde.

Ich erhalte diesen Fehler immer in der Azure-Pipeline. Bisher habe ich festgestellt, dass bei verschiedenen Gelegenheiten Folgendes für mich behoben wurde: 1. Die .suo-Datei nicht festschreiben - wenn ja, löschen und erneut festschreiben 2. Die Ordner bin oder obj nicht festschreiben - wenn ja, löschen und erneut festschreiben 3. if Wenn ein neues Projekt hinzugefügt wird, legen Sie die Projektabhängigkeit von den Lösungseigenschaften fest. Speichern und festschreiben Sie die SLN-Datei

Ich hatte das gleiche Problem mit einem Unit-Test-Projekt, das nach dem Upgrade auf VS auf 15.9.27 nicht kompiliert werden konnte, und die Lösung zum Löschen des obj-Ordners funktionierte für mich

Eine einfache Nuget-Wiederherstellung vor dem Aufruf von MSBuild hat bei mir funktioniert. Ich habe Projekte, die auf .NET Framework 4.7.2 abzielen (nicht SDK-Stil, Legacy-Stil), die ich von der Syntax packages.config migriert habe.