Ein Teil des Pfads konnte nicht gefunden werden ... bin \ roslyn \ csc.exe

813

Ich versuche, ein Asp.net MVC-Projekt auszuführen, das von der TFS-Quellcodeverwaltung abgerufen wurde. Ich habe alle Assemblyreferenzen hinzugefügt und kann ohne Fehler oder Warnung erfolgreich erstellen und kompilieren.

Aber ich bekomme folgenden Fehler im Browser:

Ein Teil des Pfads 'C: \ B8akWorkspace \ B8akProject \ B8akSolution \ B8AK.Portal \ bin \ roslyn \ csc.exe' konnte nicht gefunden werden.

Hier ist ein vollständiger Screenshot der Fehlerseite.

Geben Sie hier die Bildbeschreibung ein

Nach einigen Tagen der Recherche habe ich verstanden, dass Roslyn eine .NET-Compilerplattform ist, die erweiterte Kompilierungsfunktionen bietet. Ich verstehe jedoch nicht, warum mein Build versucht, \ bin \ roslyn \ csc.exe zu finden, da ich weder Roslyn konfiguriert habe noch beabsichtige, Roslyn in meinem Projekt zu verwenden.

Eyad
quelle
10
Kann jemand erklären, warum dies im Rahmen der Ausführung einer kompilierten ASP.NET-Anwendung erforderlich ist? Wofür wird csc.exe verwendet?
Gregmac
1
Ich denke, dies erklärt Roslyn Beteiligung: blogs.msdn.microsoft.com/webdev/2014/05/12/…
andy250
4
Der Roslyn-Ordner wurde nicht in den Bin-Ordner kopiert. Ich habe ihn behoben, indem ich das folgende Installationspaket installiert habe. Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Abdullah Tahan
12
Die Neuinstallation von Microsoft.CodeDom.Providers.DotNetCompilerPlatform hat mein Problem behoben.
SurenSaluka
4
Ich hatte dies nach dem Öffnen meines Projekts in VS 2019. Es funktionierte zuvor in VS 2017. Ich fand, dass das Problem durch einfaches Herunterstufen von Microsoft.CodeDom.Providers.DotNetCompilerPlatform auf eine frühere Version und zurück auf die neueste Version behoben wurde. Es wurden einige Probleme in meiner .csprojDatei behoben .
Neo

Antworten:

436

Das Problem mit den Standardvorlagen für VS2015 besteht darin, dass der Compiler nicht in das Verzeichnis tfr \ bin \ roslyn \ kopiert wird, sondern in das Verzeichnis {outsir} \ roslyn \

Fügen Sie diesen Code in Ihre .csproj-Datei ein:

<Target Name="CopyRoslynFiles" AfterTargets="AfterBuild" Condition="!$(Disable_CopyWebApplication) And '$(OutDir)' != '$(OutputPath)'">
    <ItemGroup>
      <RoslynFiles Include="$(CscToolPath)\*" />
    </ItemGroup>
    <MakeDir Directories="$(WebProjectOutputDir)\bin\roslyn" />
    <Copy SourceFiles="@(RoslynFiles)" DestinationFolder="$(WebProjectOutputDir)\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
</Target>
Mitchell
quelle
9
Dies löst mein Problem nicht. Jetzt erhalte ich die Datei 'C: \ B8akWorkspace \ B8akProject \ B8akSolution \ B8AK.Portal \ bin \ roslyn \ csc.exe' konnte nicht gefunden werden . Bitte beachten Sie, dass beim Erstellen eines neuen MVC-Projekts in VS2015 die erwähnte Konfiguration in .csproj nicht angezeigt wird und sie im Browser einwandfrei ausgeführt wird
Eyad,
4
Vielen Dank. Ich kann das Projekt jetzt im Browser erstellen und ausführen, nachdem ich das Roslyn-Verzeichnis heruntergeladen und im Ordner / bin abgelegt habe. Ich habe das oben erwähnte PstBuildEvent nicht platziert und es funktioniert immer noch. Vielleicht möchten Sie Ihre Antwort oben bearbeiten und die Notwendigkeit erwähnen, die Roslyn-Dateien manuell zu platzieren und die Lösung besser widerzuspiegeln.
Eyad
2
Nun, in einer normalen Situation; Sie sollten den Compiler in Ihrem Ordner $ (OutDir) roslyn *. * haben, damit dieses Skript den Compiler in den Bin-Ordner Ihres Projekts kopiert. Anscheinend enthielt Ihre Installation von vs2015 den Compiler nicht.
Mitchell
9
Ich habe festgestellt, dass die Aktualisierung von Microsoft.CodeDom.Providers.DotNetCompilerPlatform auf 1.0.8 und Microsoft.Net.Compilers 2.6.1 mir sehr geholfen hat. Ich musste dieses zusätzliche Ziel nicht hinzufügen. Es sieht so aus, als ob in einer späteren Version des Tools etwas Ähnliches hinzugefügt wurde: github.com/aspnet/RoslynCodeDomProvider/commit/…
Ian Robertson
5
Ich habe die Version von Microsoft.Net.Compilers vom Nuget auf Version 2.10.0 aktualisiert und es war die Lösung für mich. Ich benutze targetFramework = "4.6.2"
juanytuweb
1163

TL; DR

Führen Sie dies in der Package Manager-Konsole aus:

Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

Mehr Informationen

Dieses Problem hängt nicht mit Visual Studio selbst zusammen. Antworten, die das Hinzufügen von Erstellungsschritten zum Kopieren von Dateien vorschlagen, sind daher eher eine Problemumgehung. Gleiches gilt für das manuelle Hinzufügen von Compiler-Binärdateien zum Projekt.

Der Roslyn-Compiler stammt aus einem NuGet-Paket und es gab / gab einen Fehler in einigen Versionen dieses Pakets (ich weiß nicht genau, welche). Die Lösung besteht darin, dieses Paket neu zu installieren / auf eine fehlerfreie Version zu aktualisieren. Ursprünglich, bevor ich die Antwort im Jahr 2015 schrieb, habe ich sie behoben, indem ich folgende Pakete in bestimmten Versionen installiert habe:

  • Microsoft.Net.Compiler 1.1.1
  • Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.1

Dann habe ich in .csproj nachgesehen und sichergestellt, dass die Pfade zu Paketen (in meinem Fall .. \ .. \ packages \ *. *) In Tags <ImportProject>oben und <Target>unten mit dem Namen "EnsureNuGetPackageBuildImports" korrekt sind. Dies ist unter MVC 5 und .NET Framework 4.5.2 möglich.

andy250
quelle
11
Dies war mein Problem - der Ordner bin / roslyn ist vorhanden, wenn ein Projekt erstellt wird. Wenn Sie es jedoch löschen oder wie die Quellcodeverwaltung nicht kopiert werden, wird es nicht neu erstellt. Ich denke, es gibt ein kleines "Synchronisierungs" -Problem mit den Versionen. Sobald 1.0.1 installiert ist und die Datei "Import in proj" auf die richtige Version aktualisiert, kopiert ein Build automatisch den Roslyn-Ordner - es ist keiner dieser Beiträge erforderlich Befehle erstellen.
Jester
16
Ich bin mir ziemlich sicher, dass dies die beste Lösung ist ... versuche es selbst mit einem Update-Paket -reinstall -projectname myprojectname
cr1pto
5
Nach all dem hat sich für mein Projekt nichts geändert. Der Ordner bin ist immer noch abgeflacht.
Brian
8
Ein Hinweis: Version 1.0.3 des Microsoft.CodeDom.Providers.DotNetCompilerPlatform Nuget-Pakets funktioniert für mich, aber Version 1.0.6 verursacht den Fehler in dieser Frage.
Daniel Neel
5
1.0.6 hat einen Fehler: github.com/aspnet/RoslynCodeDomProvider/issues/13
akatakritos
176

Ihr Build versucht zu finden, \bin\roslyn\csc.exeda die folgenden Pakete zu Ihrem Projekt hinzugefügt wurden. Überprüfen Sie einfach Ihre packages.configDatei, Sie können beide dort haben

Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Microsoft.Net.Compilers

Was ist Roslyn und wer hat sie (Pakete) zum Projekt hinzugefügt? Wenn Sie .net Framework 4.5.2 zum Erstellen von Projekten mit VS2015 verwenden, haben Sie möglicherweise bemerkt, dass die Projektvorlagen standardmäßig Roslyn verwenden. Eigentlich ist Roslyn einer der Open-Source- Compiler für .NET-Sprachen von Microsoft.

Warum sollten wir Roslyn löschen? Wenn Ihr Projekt Roslyn-Referenzen enthält und Sie daran interessiert sind, es ohne Server bereitzustellen, werden unerwünschte Fehler auf der Website angezeigt, da viele Hosting-Anbieter ihre Server noch nicht aktualisiert haben und daher Roslyn nicht unterstützen. Um dieses Problem zu beheben, müssen Sie den Roslyn-Compiler aus der Projektvorlage entfernen.

Wenn Sie nicht an der Verwendung von Roslyn interessiert sind, führen Sie die folgenden Schritte aus, um es zu löschen

1. Entfernen Sie NuGet-Pakete und verwenden Sie die folgenden Befehle in der Nuget Package Console

PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
PM> Uninstall-package Microsoft.Net.Compilers

2. Danach sollte Ihre Datei web.config automatisch aktualisiert werden. Falls dies nicht der Fall ist, suchen Sie nach dem folgenden Code in der web.configDatei. Wenn er gefunden wird, löschen Sie diesen Code.

<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>
      <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+"></compiler>
    </compilers>
</system.codedom>
Malik Khalil
quelle
28
Dies ist keine wirkliche Lösung, wenn Sie den neuen Compiler und die neuen Funktionen tatsächlich verwenden möchten .
Matti Virkkunen
14
Sie setzen sich gegen die Zukunft ein.
Cchamberlain
2
@cchamberlain warum ist es die Zukunft? Ich denke nur, dass es einfach zu bedienen sein sollte, aber es sieht so aus, als hätten viele Leute Probleme damit.
Alisson
1
@Alisson - Roslyn ist die Richtung, in die sich die Dinge entwickeln. Es enthält neuere Sprachfunktionen, ist leistungsfähiger, plattformübergreifender und Open Source. Es kam nach den anderen Werkzeugen heraus - daher Zukunft. Nichts sagt, dass Sie es verwenden müssen, die meisten Upgrades verursachen einige Kosten. Siehe "Warum Roslyn-Kompilierung in ASP.NET?" Abschnitt: blogs.msdn.microsoft.com/webdev/2014/05/12/…
cchamberlain
1
Wenn Sie ein MVC-Projekt auf GoDaddy Shared Windows Hosting veröffentlichen möchten, ist dies die Antwort. GoDaddy führt keine ausführbaren Dateien wie csc.exe
Jeson Martajaya
141

Ein sauberer und umgebauter hat bei mir funktioniert!

Pipedreambomb
quelle
4
Ich glaube nicht, dass die Reinigung erforderlich ist. Nach dieser Diskussion des Problems wird bei einer Neuerstellung , die keine reguläre Erstellung ist, die Roslyn-Datei immer zurückgesetzt. github.com/dotnet/roslyn/issues/15556
leemicw
Ich habe auch einfach Build> Rebuild Solution ausgeführt und der Fehler ist verschwunden.
Matt Merrill
Rebuild für mich gelöst, bemerkte ich dies in der AusgabeCopying file from "C:\Users\medmondson\Source\UK\Portal\Branches\v12\Source\packages\Microsoft.Net.Compilers.1.3.2\tools\csi.exe" to "bin\Debug\roslyn\csi.exe".
m.edmondson
12
Nur die Neuerstellung hat bei mir nicht funktioniert. Nach Clean + Rebuild ist der Fehler verschwunden.
Bruno Miquelin
2
DotNetCompilerPlatform 1.0.3, Microsoft.Net.Compilers 1.3.2, VS Pro 2017 15.9.4 hier. Ein Clean / Rebuild hat bei mir auch vor und nach dem Neustart von Visual Studio nicht funktioniert. Schließlich hat ein Build> Batch Build ...> Rebuild All den Trick gemacht. Es muss genau das richtige süße Flüstern geflüstert haben, damit VS erkennt, dass das bin / roslyn-Verzeichnis in der Ausgabe fehlt.
Johann
59

Hier ist eine MSBuild-Methode, um dies zu tun.

<Target Name="CopyRoslynFiles" AfterTargets="AfterBuild" Condition="!$(Disable_CopyWebApplication) And '$(OutDir)' != '$(OutputPath)'">
    <ItemGroup>
      <RoslynFiles Include="$(CscToolPath)\*" />
    </ItemGroup>
    <MakeDir Directories="$(WebProjectOutputDir)\bin\roslyn" />
    <Copy SourceFiles="@(RoslynFiles)" DestinationFolder="$(WebProjectOutputDir)\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
</Target>

Ich stelle jedoch fest, dass sich die Roslyn-Dateien auch in meinem bin-Verzeichnis befinden (nicht in einem Ordner). Die App scheint jedoch zu funktionieren.

Rob Cannon
quelle
4
Sie können es an einer beliebigen Stelle in Ihrer .csproj-Datei auf derselben Ebene wie ein anderes <Ziel> -Tag ablegen. Normalerweise lege ich es nach unten.
Rob Cannon
Dies sollte wirklich die akzeptierte Antwort sein. Sie können dies in die Quelle einchecken und der nächste arme Trottel, der Ihr Repo zieht, muss nicht das gleiche Problem durchlaufen.
Andrew Clear
37

Wie in einer Ausgabe im Roslyn-Projekt auf GitHub erwähnt , besteht eine Lösung (die für mich funktioniert hat) darin, das Projekt einfach in Visual Studio zu entladen und neu zu laden.

Der Ordner "bin \ roslyn" wurde erst beim Erstellen oder erneuten Erstellen erstellt, als ich das Projekt neu geladen habe.

Christian Davén
quelle
Danke, es hat bei mir funktioniert. Das Problem im Dotnet-Repository war 2016 offen und wir haben dieses Problem immer noch im Visual Studio 2019. Ich kann nicht glauben, dass es echt ist!
Felipe Oriani
26

Ich habe diese Schritte befolgt und es hat perfekt funktioniert

  • Löschen Sie alle Ordner bin und obj
  • Lösung reinigen und neu aufbauen
  • Führen Sie diesen Befehl in Powershell aus

Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

Masoud Darvishian
quelle
22

Nachdem ich alle Korrekturen ohne Zigarre ausprobiert hatte, habe ich sie behoben, indem ich dieses Nuget-Paket in Visual Studios aktualisiert habe:

Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Meins war von 1.0.0 bis 2.0.0 als Referenz (Der Fehler wird nicht mehr angezeigt)

josh.thomson
quelle
3
Das war es auch für mich. Selbst 2.0.0 war zu niedrig für mein Projekt, es verlangte 2.0.1.
Yesman
3
Das hat es für mich gelöst. Ich habe ein Downgrade durchgeführt, das das Problem behoben haben muss, und dann wieder auf den neuesten Stand gebracht.
Daniel Jackson
1
Ich habe das auch getan. Jetzt wird der roslynOrdner in meinem Ausgabepfad erstellt. Ich sehe auch keine "Roslyn" -Referenz in meinem csproj. Es könnte sein, dass dies Target Name="CopyRoslyn...eine VS2015-Sache ist und in (der Version von) 2017, die ich habe, nicht notwendig ist. Bemerkenswert: Da ich DotnetCompilerPlatform aktualisiert habe, bevor ich mit dem Hinzufügen eines Kopierziels (dem von mir erwähnten) herumgespielt habe, habe ich ein saubereres csproj.
LosManos
1
Dieser ist mir gerade passiert. Dieser Beitrag ist ein Lebensretter. Ich habe dieselbe Fehlermeldung wiederholt und es scheint immer ein ganz anderer Grund zu sein!
Brian Knoblauch
19
  1. Saubere Lösung
  2. Lösung neu erstellen, Diese beiden Schritte haben bei mir funktioniert.
Nischa
quelle
Danke, das hat auch bei mir funktioniert.
Joey Phillips
1
Funktioniert. Ich habe versehentlich gedrückt, Ctrl Cals ich gerade einen Zweig gitauscheckte, und es hat mein Repo vermasselt. git reset --hardhat nicht funktioniert, also musste ich git clean -xdfdas Projekt neu aufbauen. Allerdings bin ich auf diesen Fehler gestoßen, also habe ich das Projekt einfach bereinigt und neu erstellt und es hat bei mir funktioniert.
Paul Carlton
15

NuGet Package Manager

Sie müssen Microsoft.CodeDom.Providers.DotNetCompilerPlatform.BinFix installieren, das speziell für diesen Fehler erstellt wurde

Adrian Berca
quelle
Das hat nicht funktioniert - ich vermute, dass das Paket nicht genau für diesen Zweck ist.
Drew Miller
Ich habe mit VS 2017 getestet und es funktioniert gut, es könnte ein Problem mit anderen Versionen sein.
Juan Acosta
11
Ich installiere keine zufälligen Pakete von zufälligen Personen mit 'dsx' als Spitznamen. Das ist große Sicherheit nein ...
Mateusz
1
@Mateusz oder eine, die meine Nicht-APS.NET-Ordnerstruktur reparieren würde
Eliasar
14
  • Klicken Sie mit der rechten Maustaste auf Ihr Projekt und wählen Sie Nuget-Pakete verwalten
  • Suchen Sie "Microsoft.CodeDom.Providers.DotNetCompilerPlatform"
  • Aktualisieren Sie einfach auf eine ältere oder neuere Version (egal welche) und aktualisieren Sie dann erneut auf Ihre ursprüngliche Version.

Dadurch werden alle Abhängigkeiten und Dateien des Pakets (wie csc.exe) neu installiert.

Nuget - DotNetCompilerPlatform

Bojan
quelle
Das hat es für mich behoben! Vielen Dank!
Mason
11

Also, Rob Cannons Antwort war im Wesentlichen für mich, aber ich hatte eine Handvoll Optionen zwicken. Insbesondere musste ich die Bedingung auf dem Ziel entfernen und das Include-Attribut ändern, da $ CscToolPath leer war, als das Projekt auf unserem Build-Server erstellt wurde. Seltsamerweise war $ CscToolPath beim lokalen Ausführen NICHT leer.

<Target Name="CopyRoslynFiles" AfterTargets="AfterBuild" >
  <ItemGroup>
    <RoslynFiles Include="$(SolutionDir)packages\Microsoft.Net.Compilers.1.1.1\tools\*" />
  </ItemGroup>
  <MakeDir Directories="$(WebProjectOutputDir)\bin\roslyn" />
  <Copy SourceFiles="@(RoslynFiles)" DestinationFolder="$(WebProjectOutputDir)\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
</Target>
Jonnybot
quelle
1
Das Verhalten ist noch schlimmer. Vor Ort, wenn Sie zu Ihrem gehen Paket - Ordner und die beiden Ordner löschen Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.nn und Sie Code bauen, dann wird das $ CscToolPath leer sein. Wenn Sie ein zweites Mal bauen, wird es nicht leer sein. Das Problem tritt ständig auf Ihrem Build-Server auf, da es immer als "erster Build" betrachtet wird. Ihr Code funktioniert einwandfrei. Wenn Sie jedoch das Microsoft.Net.Compilers- Paket aktualisieren , müssen Sie die .csproj-Datei aktualisieren . Vielen Dank.
Julien D.
3
Beachten Sie, dass diese Lösung fehlschlägt (oder angepasst werden muss), wenn sich die Version von Microsoft.Net.Compilers ändert.
JanDotNet
Ich habe die Microsoft.CodeDom.Providers.DotNetCompilerPlatform aktualisiert und konnte dann fortfahren.
iowatiger08
10

Das Aktualisieren von Nuget-Paketen hat bei mir funktioniert Klicken Sie mit der rechten Maustaste auf die Lösung> NuGet-Pakete für die Lösung verwalten und aktualisieren Sie alle Pakete und insbesondere Microsoft.Net.Compilers und Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Hichamkazan
quelle
Diesmal hat das bei mir funktioniert. Der fehlende Roslyn / csc.exe-Fehler tritt bei mir ständig auf und die Lösung ist ziemlich oft anders ...
Brian Knoblauch
10

Dies ist ein bekanntes Problem mit Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.6. Ein Downgrade auf 1.0.5 hat dies für mich behoben.

jrummell
quelle
Dies ist richtig. Ich bin auf dieses Problem mit Version 1.0.6 nur beim Veröffentlichen in Azure gestoßen. Herabstufung auf 1.0.5 funktioniert
Augusto Barreto
Herabgestuft von 2.0.0 auf 1.0.5 und es hat funktioniert. Zu der Zeit aß ich jedoch ein Truthahnsandwich, das wahrscheinlich teilweise für die Lösung verantwortlich war. Stelle dir das vor.
Barneymc
10

Entfernen Sie für VS 2019 den folgenden Knoten vollständig:

<system.codedom>
</system.codedom>
Shadi Namrouti
quelle
9

Per Kommentar von Daniel Neel oben:

Version 1.0.3 des Microsoft.CodeDom.Providers.DotNetCompilerPlatform Nuget-Pakets funktioniert für mich, aber Version 1.0.6 verursacht den Fehler in dieser Frage

Ein Downgrade auf 1.0.3 hat dieses Problem für mich behoben.

Jason Coyne
quelle
3
1.0.6 hat einen Fehler: github.com/aspnet/RoslynCodeDomProvider/issues/13
akatakritos
@akatakritos das hat geholfen. Ich habe stundenlang gesucht. Danke euch beiden.
Erincerol
2
1.0.7 ist in bestimmten Szenarien immer noch betroffen github.com/aspnet/RoslynCodeDomProvider/issues/17
auch
1
1.0.5 ist die neueste Version, die für mich funktioniert hat (1.0.6 und 1.0.7 erzeugen den Fehler)
Patrick
Ich war 1.0.7 und es würde nicht funktionieren. 1.0.3 funktioniert. Ich habe nichts Höheres ausprobiert, da ich gerade die letzte Stunde meines Lebens mit diesem Problem verschwendet habe und jetzt nicht mehr damit herumspiele, jetzt funktioniert es!
Philip Stratford
9

In meinem Fall hatte ich ein Problem in Jenkins, als versucht wurde, es in Octopus mit folgendem Fehler bereitzustellen:

MSBUILD : OctoPack error OCT-1676060969: Failed to build the path for '\bin\roslyn\csc.exe' relative to 'T:\workspace\machine.engine\Machine.engine.Test': Invalid URI: The format of the URI could not be determined.. See the inner exception for more details. [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969: System.Exception: Failed to build the path for '\bin\roslyn\csc.exe' relative to 'T:\workspace\machine.engine\Machine.engine.Test': Invalid URI: The format of the URI could not be determined.. See the inner exception for more details. ---> System.UriFormatException: Invalid URI: The format of the URI could not be determined. [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind) [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at System.Uri..ctor(String uriString) [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at OctoPack.Tasks.Util.OctopusPhysicalFileSystem.GetPathRelativeTo(String fullPath, String relativeTo) in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\Util\OctopusPhysicalFileSystem.cs:line 211 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    --- End of inner exception stack trace --- [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at OctoPack.Tasks.Util.OctopusPhysicalFileSystem.GetPathRelativeTo(String fullPath, String relativeTo) in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\Util\OctopusPhysicalFileSystem.cs:line 224 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at OctoPack.Tasks.CreateOctoPackPackage.AddFiles(XContainer nuSpec, IEnumerable`1 sourceFiles, String sourceBaseDirectory, String targetDirectory, String relativeTo) in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\CreateOctoPackPackage.cs:line 443 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
MSBUILD : OctoPack error OCT-1676060969:    at OctoPack.Tasks.CreateOctoPackPackage.Execute() in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\CreateOctoPackPackage.cs:line 190 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj]
Done Building Project "T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj" (default targets) -- FAILED

Ursache

Nachdem ich einige Zeit verbracht hatte, verwendete ich eine intern entwickelte Komponente, die verwendet wurde Microsoft.Net.Compilers. Der Grund, warum die interne Komponente verwendet wurde, Microsoft.Net.Compilerswar die Behebung dieses Problems ( C #: Kompilierung ungültiger Ausdrücke auslösen ) und wurde auf diese Weise gelöst ( Verwendung von C # 7 mit Visual Studio 2015? ). Wenn ich die Komponente im Hauptprogramm installiert habe, wird Microsoft.Net.Compilerssie automatisch hinzugefügt.

Lösung

Meine Problemumgehung bestand darin, von unserer internen Komponente zu deinstallieren (nach der Antwort von @malikKhalil)

PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
PM> Uninstall-package Microsoft.Net.Compilers

Wählen Sie in Jenkins den C # 7-Compiler anstelle von C # 6 und erstellen Sie ihn neu, um sicherzustellen, dass alles ordnungsgemäß funktioniert und erstellt wird.

Als ich schließlich in meinem Hauptprogramm versuchte, meine interne Komponente zu aktualisieren. Und alles als wieder aufzubauen. Es hat ohne Probleme oder Probleme gebaut.

Maytham-ɯɐɥʇʎɐɯ
quelle
8

In meinem Fall musste ich nur in das Verzeichnis bin in Visual Studio Solution Explorer (Webanwendungsprojekt) wechseln und das Roslyn-Projekt direkt einschließen. Klicken Sie mit der rechten Maustaste auf den Ordner und wählen Sie In Projekt einschließen. Überprüfen Sie die Lösung erneut, um den Erstellungsprozess auszulösen.

Der Roslyn-Ordner war standardmäßig nicht enthalten.

Martijn van Halen
quelle
7

Ich hatte auch das gleiche Problem beim Ausführen des Projekts. Hier sind die Schritte, die ich befolgt habe.

  1. Klicken Sie mit der rechten Maustaste in die Lösung
  2. Wählen Sie Lösung reinigen
  3. Nachdem die Reinigung erfolgreich war, erstellen Sie Ihr Projekt erneut
  4. Führen Sie das Projekt erneut aus

Diesmal habe ich nicht den gleichen Fehler gesehen. Dies funktioniert wie erwartet.

Narendra
quelle
Kollegen berichteten, dass das Aktualisieren des NuGet-Pakets über die Konsole funktioniert, dies funktioniert jedoch auch ohne Ausführung eines Befehls. Meine gewählte Antwort.
Tsemer
7

Ein Upgrade Microsoft.CodeDom.Providers.DotNetCompilerPlatformvon 1.0.0 auf 1.0.1 hat dies für mich behoben.

Ben
quelle
6

Öffnen Sie die Projektdatei und entfernen Sie alle Verweise mit Import Project = ".. \ packages \ Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0 ....

Öffnen Sie web.config und entfernen Sie alle Compilerattribute von system.codedom

user6326076
quelle
6

Wie bereits angemerkt /programming/32780315#34391473 , die schnelle Lösung den Paket - Manager zu verwenden ist, Tools> Nuget Package Manager> Package Manager Console, laufen

Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

Packet Manager Console - Öffnen

Eine alternative Lösung (die Ihre Pakete automatisch und unbeaufsichtigt neu erstellt, wenn sie fehlen) besteht darin, ein Attribut aus der Web.configDatei Ihres Projekts zu entfernen .
( Web.configbefindet sich im selben Verzeichnis wie Ihre .csprojDatei.)

Öffnen Sie die Web.configDatei in einem Texteditor (oder in Visual Studio).
- Im Tag configuration> system.codedom> compilers> compiler language="c#;cs;csharp", entfernen Sie vollständig das typeAttribut.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <!-- ... -->
  <system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs"
        type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        warningLevel="4" compilerOptions="/langversion:default /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.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+"/>
    </compilers>
  </system.codedom>
</configuration>

Kurz gesagt, entfernen Sie die Zeile, die mit beginnt type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.

(Vermutlich funktioniert das gleiche Update sowohl für Visual Basic als auch für Csharp, aber ich habe es nicht ausprobiert.)

Visual Studio kümmert sich um den Rest. Nicht mehr Server Error in '/' Application.

In dem Beispielcode, den ich oben in der Zip-Datei angegeben habe, erhalten Sie jetzt, HTTP Error 403 wenn Sie Ctrl+ drücken F5.

HTTP-Fehler 403.14 - Verboten

Versuchen Sie, http://localhost:64195in Ihrem Webbrowser durch zu ersetzen http://localhost:64195/api/products.
Die Web-API wird jetzt wie folgt angezeigt:

Eine Web-API, die Produkte enthält

Als Provokation habe ich versucht, das gesamte packageVerzeichnis meiner Visual Studio-Lösung zu entfernen .
Es wurde automatisch und stillschweigend neu erstellt, sobald ich es (neu) gebaut habe.


Zu guter Letzt gibt es hier Code, der den Fehler reproduziert: http://schulze.000webhostapp.com/vs/SrvrErr-reproduce.zip (Ursprünglich von https://github.com/aspnet/AspNetDocs/tree/master/aspnet / Web-API / Übersicht / Erweitert / Aufrufen einer Web-API von einem Netz-Client / Beispiel / Server / ProdukteApp )

Serverfehler

Henke
quelle
6

In meinem Fall hat das Löschen von allem im Ordner bin und das Neukompilieren die ganze Arbeit für mich erledigt.

Juan Martí
quelle
2
Ich denke, das ist einfacher und effektiver. Normalerweise erhalte ich diesen Fehler, nachdem ich ein Projekt aus einem Repository in ein neues Computer geklont habe.
Jonathan Ortega
Nachdem ich dies versucht hatte, wurde mir beim Ausführen im Debugger 403 Forbidden von IIS Express angezeigt. Ein Neustart von Visual Studio hat ebenfalls nicht geholfen, ein Neustart von Windows jedoch.
Florian Winter
5

Wenn Sie ASPNETCOMPILER hinzugefügt haben, um Ihre Razor-Ansichten in MVC zu kompilieren, wie in dieser StackOverflow-Frage , ändern Sie PhysicalPath an die Stelle, an der sich das Roslyn-Nuget-Paket befindet (normalerweise über die Variable $ CscToolPath ):

<Target Name="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(CscToolPath)" />

Anrijs Vītoliņš
quelle
5

Das Problem mit den Standard-VS2015-Vorlagen besteht darin, dass der Compiler nicht in das {outdir}_PublishedWebsites\tfr\bin\roslyn\Verzeichnis, sondern in das {outdir}\roslyn\Verzeichnis kopiert wird . Dies unterscheidet sich wahrscheinlich von Ihrer lokalen Umgebung, da AppHarborApps mithilfe eines Ausgabeverzeichnisses erstellt werden, anstatt die Lösung "direkt" zu erstellen.

Um dies zu beheben, fügen Sie am Ende der .csprojDatei direkt nach dem XML-Block Folgendes hinzu<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">...</Target>

<PropertyGroup>
  <PostBuildEvent>
    if not exist "$(WebProjectOutputDir)\bin\Roslyn" md "$(WebProjectOutputDir)\bin\Roslyn"
    start /MIN xcopy /s /y /R "$(OutDir)roslyn\*.*" "$(WebProjectOutputDir)\bin\Roslyn"
  </PostBuildEvent>
</PropertyGroup>

Referenz: https://support.appharbor.com/discussions/problems/78633-cant-build-aspnet-mvc-project-generated-from-vstudio-2015-enterprise

Korayem
quelle
1
Die Option / d kopiert nur neuere Dateien (steht für "Datum"). Denken Sie daran, die Bereitstellung in Cloud / Azure durchzuführen, wo die Zeit hinter / vor der Ortszeit liegen kann.
Max
4

In meinem Fall gab es ähnlich wie in Basim ein NuGet-Paket, das dem Compiler mitteilte, dass wir C # 6 brauchten, was wir nicht taten.

Wir mussten das NuGet-Paket entfernen Microsoft.CodeDom.Providers.DotNetCompilerPlatform das dann entfernt wurde:

  1. <package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.0" targetFramework="net452" /> aus der Datei packages.config
  2. <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>

Im system.codedomKnoten können Sie sehen, warum Roslyn hereingebracht wurde:compilerOptions="/langversion:6

Mark C.
quelle
1
Alles was ich tun musste, war das NuGet-Paket "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" zu deinstallieren und das löste es für mich (mein Projekt zielt auf .NET 4.5.2 ab).
BlueSky
1
Das hat bei mir funktioniert. Sie sollten auch Microsoft.Net.Compiler entfernen, da es keinen Grund gibt, diese zusätzliche Abhängigkeit beizubehalten.
Immer lernen
4

Löschen Sie den Ordner Bin in Ihrem Lösungs-Explorer und erstellen Sie die Lösung erneut. Das würde das Problem lösen

user1903050
quelle
Vielen Dank! Das hat auch bei mir funktioniert. Außerdem habe ich alle meine Nuget-Pakete aktualisiert
Andre Kraemer
4

Ich hatte das gleiche Problem bei der Installation meiner Anwendung auf dem Server, als auf localhost alles einwandfrei funktionierte.

Keine dieser Lösungen hat funktioniert, ich hatte immer den gleichen Fehler:

Could not find a part of the path 'C:\inetpub\wwwroot\myApp\bin\roslyn\csc.exe'

Am Ende habe ich das gemacht:

  • Klicken Sie in meinem Setup-Projekt rechts auf Ansicht> Dateisystem
  • Erstellen Sie einen bin/roslynOrdner
  • Wählen Sie Hinzufügen> Dateien und fügen Sie alle Dateien aus hinzu packages\Microsoft.Net.Compilers.1.3.2\tools

Dies löste mein Problem.

Alexandre Hamon
quelle
4

Starten Sie Windows neu.

Dies ist die einzige Lösung, die für mich funktioniert hat, nachdem ich versucht habe, binVisual Studio neu zu erstellen, Inhalte zu löschen und neu zu erstellen und neu zu starten.

Dies ist ein weiteres Beispiel dafür, wie schrecklich C # /. NET-Build-Tools sind.

Ich denke (nach dem Lesen vieler Antworten) ist die allgemeine Schlussfolgerung, dass die Ursache und Lösung dieses Problems stark vom Setup und Projekt abhängt. Wenn also eine Antwort nicht funktioniert, versuchen Sie es einfach mit einer anderen. Probieren Sie zunächst nicht störende / zerstörerische Lösungen aus, z. B. einen Neustart von Visual Studio, einen Neustart, eine Neuerstellung usw., bevor Sie mit NuGet-Paketen herumspielen oder Entwicklungstools neu installieren. Viel Glück!

(HINWEIS: Die Verwendung von Visual Studio 2019 und der Projektdatei wurde ursprünglich in Visual Studio 2015 erstellt. Möglicherweise hilft dies jemandem, das Problem zu untersuchen.)

(BEARBEITEN: Kann dies daran liegen, dass nach der Installation / Änderung der Visual Studio-Installation oder der Aktualisierung von Visual Studio kein Neustart durchgeführt wird, wenn das Installationsprogramm zum Neustart auffordert?)

Florian Winter
quelle
3

Ich habe ein Webprojekt ohne csproj-Datei und die hier erwähnten Lösungen haben bei mir nicht funktioniert.

Das Ändern des Ziel-.NET-Frameworks, das Neuinstallieren von Paketen ( Update-Package -reinstall) und das anschließende Erstellen des Projekts haben bei mir funktioniert. Sie können das Ziel-Framework nach diesem Vorgang sogar wieder ändern (stellen Sie sicher, dass Sie die Nuget-Pakete danach erneut installieren).

Miroslav Adamec
quelle
Dies ist ein "Website-Projekt". Ich habe diesen Befehl verwendet, um nur das eine Paket neu zu installieren:update-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -reinstall
GarDavis