VS 15.8.2 hat Build-Tools kaputt gemacht - RuntimeIdentifier fehlt

78

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.

TomTom
quelle
Identisches Problem hier, dasselbe Legacy-Projekt, dieselbe VS-Version.
JohnKoz
TomTom - hast du es gelöst? Ich habe jetzt das gleiche Problem.
Uri Y
Einfach verschwunden, wie es scheint. Denken Sie daran, wir sind jetzt am 15.8.6 ...
TomTom

Antworten:

126

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

Señor CMasMas
quelle
1
Nee. Nicht das. Ich nuke den ganzen Ordnerbaum - muss sogar bei jedem Build einen vollen Git bekommen. Kein Build.
TomTom
11
Durch das Löschen des obj-Ordners in jedem meiner Projekte in der Lösung wurde dieser Fehler für mich behoben.
Adrian Sanguineti
1
Ich habe in einen neuen Ordner ausgecheckt, immer noch das gleiche Problem. Dies begann jetzt nach dem Upgrade auf 15.9.4, normales .net Framework csproj. Für mich geschieht dies auf der Kommandozeile mit msbuild, Visualstudio Builds gut.
NeslekkiM
5
Ich habe auch den gleichen Fehler mit VS 15.9.9. Das Problem tritt nur bei der Befehlszeile devenv auf. Nicht über die VS-GUI.
David
3
Für zukünftige Referenzzwecke kann dies passieren, wenn Sie zu PackageReference und zurück wechseln und Rückstände hinterlassen. offene Ausgabe: github.com/dotnet/project-system/issues/3164
Daniel Dubovski
24

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
Ausstehende Rechnung
quelle
Ich habe das Projekt in das neue SDK-Format konvertiert, es erstellt und meine Änderungen rückgängig gemacht. Dann habe ich diesen project file doesn't list 'win' as a "RuntimeIdentifier"Fehler für csproj Legacy-Format. Ich habe alle entfernt binund objDateien , die erstellt wurden , während sie mit neuem Projektformat zu spielen und es begann wieder zu kompilieren.
Oleksa
24

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

Bahaa
quelle
3
Das hat bei mir funktioniert. Ich mische .Net Standard- und .Net Framework-Projekte. Dies war für alle .cetj-Dateien des .Net Framework erforderlich, damit die Lösung über die Befehlszeile erstellt werden konnte.
Russell Phillips
1
Dies funktionierte für mich in einem Fall, in dem ich das Projekt auf Nuget im PackageReference-Stil migriert hatte.
RosieC
1
Warum wird es dann in Visual Studio und von msbuild in der Kommandozeile erstellt .. aber bricht in Azure?
Piotr Kula
11

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

llotall
quelle
Einfach und effektiv. Ich musste nur entfernen binund obj... Vielen Dank
Andre Soares
Danke ... ersparte mir das Durchsuchen von 89 Projektordnern.
Peter
1
Nett. Alternativ rm *\obj -Recurse -Forcefunktioniert auch
Subjektive Realität
5

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

eva
quelle
2

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
Icewindq Liu
quelle
Das Upgrade von nuget.exe von v4.9.4.5839 auf v5.4.0.6315 hat dieses Problem für mich gelöst.
Blaz
2

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

Simon Mourier
quelle
1

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,

Ed Dore
quelle
1

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\**

SliverNinja - MSFT
quelle
0

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

Däne Bouchie
quelle
0

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));
Lawinen
quelle
0

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.

Martin Dimitrov
quelle
0

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

Ian Mercer
quelle
0

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.

nf313743
quelle
0

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

Subha
quelle
0

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

user76713
quelle
0

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.

Nikhil
quelle