Konnte keinen Teil des Pfades finden … bin \ roslyn \ csc.exe

Ich versuche, Asp.net MVC-Projekt von TFS-Quellcodeverwaltung abgerufen. Ich habe alle Assemblyreferenzen hinzugefügt und bin in der Lage, ohne Fehler oder Warnung erfolgreich zu kompilieren und zu kompilieren.

Aber ich bekomme folgende Fehlermeldung im Browser:

Es konnte kein Teil des Pfades ‘C: \ B8akWorkspace \ B8akProject \ B8akSolution \ B8AK.Portal \ bin \ roslyn \ csc.exe’ gefunden werden.

Hier ist ein vollständiger Screenshot der Fehlerseite.

Bildbeschreibung hier eingeben

Nach ein paar Tagen Forschung habe ich verstanden, dass Roslyn .Net Compiler-Plattform, die im Voraus kompilierende functionen bietet. Ich verstehe jedoch nicht, warum mein Build versucht, \ bin \ roslyn \ csc.exe zu finden, weil ich nichts in Bezug auf Roslyn konfiguriert habe oder Roslyn in meinem Projekt verwenden möchte.

    Das Problem mit den VS2015-Standardvorlagen besteht darin, dass der Compiler nicht tatsächlich in das Verzeichnis tfr \ bin \ roslyn \ kopiert wird, sondern in das Verzeichnis {outdir} \ roslyn \

    Fügen Sie diesen Code in Ihrer .csproj-Datei hinzu:

           

    In meinem Fall bestand die Lösung darin, Nuget-Pakete neu zu installieren / zu aktualisieren:

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

    Dann schaute ich in .csproj und stellte sicher, dass die Pfade zu den Paketen korrekt sind (in meinem Fall .. \ .. \ packages \ *. *) Innerhalb der Tags oben und in mit dem Namen “EnsureNuGetPackageBuildImports” an der Boden. Dies ist auf MVC 5 und .NET Framework 4.5.2.

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

    PM > update-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

    Ihr Build versucht, \bin\roslyn\csc.exe da in Ihrem Projekt folgende Pakete hinzugefügt wurden. Überprüfen Sie die Datei packages.config . Sie können beide Dateien dort haben

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

    Was ist Roslyn und wer hat sie (Pakete) im Projekt hinzugefügt: Wenn Sie .NET Framework 4.5.2 verwenden, um Projekte mit VS2015 zu erstellen, haben Sie vielleicht bemerkt, dass die Projektvorlagen Roslyn standardmäßig 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 hat und Sie kein Server bereitstellen möchten, erhalten Sie unerwünschte Fehler auf der Website, da viele Hosting-Provider ihre Server noch nicht aktualisiert haben und daher Roslyn nicht unterstützen. Um dies zu beheben Problem, Sie müssen den Roslyn-Compiler aus der Projektvorlage entfernen.

    Wenn Sie nicht an Roslyn interessiert sind, folgen Sie den Schritten unten, um es zu löschen

    1. Entfernen Sie Nuget-Pakete, verwenden Sie die folgenden Befehle von Nuget Package Console

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

    2. Nachdem Sie dies getan haben, sollte Ihre Datei web.config automatisch aktualisiert werden. Sollte dies nicht der Fall sein, suchen Sie den folgenden Code in der Datei web.config und löschen Sie diesen Code, falls er gefunden wurde.

           

    Hier ist eine MSBuild-Methode.

            

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

    Ein sauberes und wieder aufgebautes funktionierte für mich!

    Edit: Kommentatoren sagen, dass der saubere Schritt nicht notwendig ist. Sie können einfach neu erstellen.

    Also, Rob Cannons Antwort funktionierte im Wesentlichen für mich, aber ich musste eine Handvoll der Optionen optimieren. 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 bei lokaler Ausführung NICHT leer.

            

    Nach einem 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

    Downgrade auf 1.0.3 hat dieses Problem für mich getriggers.

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

    In meinem Fall musste ich nur in Visual Studio Solution Explorer (Webanwendungsprojekt) in das Verzeichnis bin gehen und das Roslyn-Projekt direkt einbinden. Klicken Sie mit der rechten Maustaste auf den Ordner, und wählen Sie In Projekt einschließen aus. Und checken Sie die Lösung erneut ein, um den Build-process auszulösen.

    Der Roslyn-Ordner wurde standardmäßig nicht eingeschlossen.

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

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

    Aktualisieren von nuget-Paketen funktioniert für mich Klicken Sie mit der rechten Maustaste auf die Lösung> NuGet-Pakete für die Lösung verwalten und aktualisieren Sie alle Pakete und speziell: Microsoft.Net.Compilers und Microsoft.CodeDom.Providers.DotNetCompilerPlatform

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

       

    Das Problem mit den VS2015-Standardvorlagen besteht darin, dass der Compiler nicht tatsächlich in das {outdir}_PublishedWebsites\tfr\bin\roslyn\ , sondern in das {outdir}\roslyn\ . Dies unterscheidet sich wahrscheinlich von Ihrer lokalen Umgebung, da AppHarbor Apps mithilfe eines Ausgabeverzeichnisses erstellt, anstatt die Lösung ” AppHarbor .

    Um das .csproj zu beheben, fügen Sie am Ende der .csproj Datei direkt nach dem XML-Block ...

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

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

    Das Aktualisieren von Microsoft.CodeDom.Providers.DotNetCompilerPlatform von 1.0.0 auf 1.0.1 hat das für mich behoben.

    In meinem Fall hatte ich ein Problem in Jenkins, als es versuchte, es in Octopus mit folgendem Fehler zu implementieren:

     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

    Nach einiger Zeit nutzte ich eine interne entwickelte Komponente, die Microsoft.Net.Compilers . Der Grund für die Verwendung von Microsoft.Net.Compilers die interne Komponente bestand darin, dieses Problem zu beheben ( C #: Ungültige Ausdruckskompilierung auslösen ) und wurde auf diese Weise getriggers ( Wie wird c # 7 mit Visual Studio 2015 verwendet? ). Dies führt dazu, dass, wenn ich die zuständigen auf dem Hauptprogramm installiert habe, die Microsoft.Net.Compilers automatisch hinzugefügt werden.

    Lösung

    Meine Arbeit war, Deinstallation von unserer internen Komponente durch (folgende @ MalikKhalil Antwort)

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

    Und wählen Sie C # 7 Compiler in Jenkins statt C # 6 und neu zu erstellen, das ist, um sicherzustellen, dass alles richtig funktioniert und baut.

    Schließlich versuchte ich in meinem Hauptprogramm meine interne Komponente zu aktualisieren. Und alles als neu bauen. Es hat ohne irgendwelche Probleme oder Probleme gebaut.

    Bildbeschreibung hier eingeben

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

    In meinem Fall, ähnlich wie bei Basim, gab es ein NuGet-Paket, das dem Compiler sagte, dass wir C # 6 benötigten, was wir nicht taten.

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

    1. aus der Datei packages.config

    Im Knoten system.codedom können Sie sehen, warum Roslyn eingeführt wurde: compilerOptions="/langversion:6

    Fügen Sie Ihrer .csproj-Datei PropertyGroup hinzu

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

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

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

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

    Ich endete damit:

    • auf meinem Setup-Projekt, rechts clic, Ansicht> Dateisystem
    • Erstellen Sie einen Ordner bin/roslyn
    • Wählen Sie Hinzufügen> Dateien und fügen Sie alle Dateien aus den packages\Microsoft.Net.Compilers.1.3.2\tools

    Das hat mein Problem getriggers.

    Ich hatte auch dasselbe Problem während der Durchführung des Projekts. Hier sind die Schritte, denen ich folgte.

    1. Rechtsklick in Lösung
    2. Wählen Sie Reinigungslösung
    3. Nachdem Clean erfolgreich war, baue erneut dein Projekt
    4. Führen Sie das Projekt erneut aus

      Diesmal sehe ich nicht den gleichen Fehler. Dies funktioniert wie erwartet

    Löschen Sie den Ordner “Bin” in Ihrem Lösungsexplorer, und erstellen Sie die Lösung erneut. Das würde das Problem lösen

    Ich bin auf dieses Problem gestoßen, nachdem ich einige Pakete über NuGet aktualisiert habe. Ein Umbau (anstelle eines normalen Builds) hat für mich funktioniert.

    Ich hatte das gleiche Problem nach der Aktualisierung von DotNetCompilerPlatform. Getriggers durch Neustart von Visual Studio> Projekt bereinigen> Projekt erstellen.

    Meine Lösung verwendet Nuget, um die folgenden Elemente auf die neueste Version zu aktualisieren: – Microsoft.Net.Compilers – Microsoft.CodeDom.Providers.DotNetCompilerPlatform Anschließend wurde das Projekt neu erstellt. Da mein Projekt eine Website ist also keine * .csproj Datei. Der obige Fehler tritt auf, als ich versuchte, einen cshtml im Browser anzuzeigen.

    Der Fehler wurde behoben, nachdem die beiden obigen Elemente auf die neueste Version aktualisiert wurden. Ich bin in VS2015 und Windows7 SP1

    Ich habe ein Webprojekt ohne csproj-Datei und hier erwähnte Lösungen funktionierten nicht für mich.

    Ziel-.NET-Framework zu Update-Package -reinstall , Pakete neu zu installieren ( Update-Package -reinstall ) und dann das Projekt zu bauen funktionierte für mich. Sie können das Zielframework nach dieser Operation sogar wieder ändern (machen Sie die Neuinstallation von nuget-Paketen erneut).

    Problem

    Beachten Sie, dass das NuGet PM das Rosalyn-Verhalten bricht. Klicken Sie auf Tools > NuGet Package Manager > Manage NuGet Packages for Solution Wenn für Microsoft.CodeDom.Providers.DotNetCompilerPlatform , Microsoft.Net.Compilers oder Microsoft.Net.Compilers.netcore Update vorhanden ist, aktualisieren Sie diese und die Lösung wird beschädigt! Dies liegt daran, dass die ASP Sites-Vorlagen so eingestellt sind, dass sie bestimmte Versionen bei der Projekterstellung verwenden. Um das Problem zu sehen, klicken Sie im Projektmappen-Explorer auf Alle Dateien anzeigen.

    Fix

    Bei der Projekterstellung existiert das $(WebProjectOutputDir)\bin nicht, daher wird es, wenn Rosalyn als eine Abhängigkeit von NuGet hinzugefügt wird, es richtig installiert. Nach dem Aktualisieren der Lösungspakete sieht das Verzeichnis $(WebProjectOutputDir)\bin so aus:

    $(WebProjectOutputDir)\bin\bin\rosalyn

    Die einfachste Lösung besteht darin, rosalyn an der richtigen Stelle auszuschneiden und einzufügen und dann den zusätzlichen bin Ordner zu löschen. Sie können jetzt die Seite aktualisieren und die Website wird geladen.

    Ich musste die WebAPI- und MVC-Projektdateien ändern, um keine Ansichten zu erstellen:

     false 

    Dies hat meinen TFS 2015 Build Servererrors bei Roslyn behoben. Immer noch nicht sicher, warum csc.exe nach \ bin \ csc.exe kopiert wurde, aber der Veröffentlichungsprozess nach \ bin \ Roslyn \ csc.exe suchte … konnte die Transformation, die diese Diskrepanz verursacht, nicht finden.

    Ich habe diesen Fehler auf einem Jenkins-Build-Server mit MSBuild festgestellt, der die Build-Dateien an einen separaten Ordner (_PublishedWebsites) ausgibt. Genau das gleiche – der Roslyn-Ordner befand sich nicht im bin-Verzeichnis, und alle roslyn-Dateien wurden mit den bin-Dateien zusammengelegt.

    @ igor-semin’s Antwort war die einzige Sache, die für mich funktionierte (da ich die C # 6-Sprachfunktionen verwende, kann ich die nugget-Pakete nicht einfach nach anderen Antworten deinstallieren), aber da ich auch CodeAnalysis verwende, bekam ich ein weiterer Fehler auf meinem Implementierungszielserver:

    Ein Versuch, eine vorhandene Zuordnung zu überschreiben, wurde für den Typ Microsoft.CodeAnalysis.ICompilationUnitSyntax mit dem Namen “” erkannt, der derzeit dem Typ Microsoft.CodeAnalysis.CSharp.Syntax.CompilationUnitSyntax zugeordnet ist, um Microsoft.CodeAnalysis.VisualBasic.Syntax.CompilationUnitSyntax einzugeben.

    Der Grund dafür ist, dass beim Kopieren der roslyn-Dateien in das Hauptverzeichnis des Hauptverzeichnisses beim Ausführen von xcopy im verschachtelten roslyn-Ordner zwei Kopien dieser Dateien kompiliert werden und es zu einem Konflikt kommt . Nach vielen Frustrationen entschied ich mich für einen ‘Hack’-Fix – eine zusätzliche Post-Build-Aufgabe, um diese Dateien aus dem bin-Verzeichnis zu löschen und den Konflikt zu beseitigen.

    Die .csproj meiner beleidigenden Projekte sieht jetzt so aus:

    ………………. mehr hier ………………….

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

    ………………. mehr hier ………………….

    Ich stieß auf dieses Problem mit der Veröffentlichungs-Pipeline (die ein _PublishedWebsites-Verzeichnis erstellt) und verwendete dies als Ziel im Projekt:

        

    Der Nachteil ist, dass es zwei Kopien der Roslyn-Dateien in der Ausgabe geben wird.

    Ich hatte diesen Fehler, nachdem ich eine Lösung und einige enthaltene Projekte umbenannt hatte, und spielte mit dem Entfernen von nuget-Paketen herum. Ich habe das neue Projekt mit dem letzten Arbeitsprojekt verglichen und festgestellt, dass die folgenden Zeilen fehlten und wieder hinzugefügt werden mussten:

         

    Dadurch wurde das Problem für mich getriggers.