Der CodeDom-Anbietertyp "Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider" konnte nicht gefunden werden

Es ist ein WebApi-Projekt mit VS2015.

Schritt zum Reproduzieren:

1. Erstellen Sie ein leeres WebApi-Projekt
2. Ändern Sie den Build-Ausgabepfad von "bin \" in "bin \ Debug \".
3. Lauf

Alles funktioniert einwandfrei, bis ich den Build-Ausgabepfad von "bin \" in "bin \ Debug \" geändert habe. Tatsächlich funktioniert kein anderer Ausgabepfad als "bin \".

Eine kleine zusätzliche Sache ist, dass ein anderer Ausgabepfad zu irgendwo funktionieren würde, solange ich einen Build in "bin \" hinterlassen habe.

Bitte helfen Sie bei der Bereitstellung einer Lösung, um dieses Problem zu lösen. Ich denke, das kostet ein Problem bei der tatsächlichen Bereitstellung.

Wenn Ihr Projekt über Roslyn-Referenzen verfügt und Sie es auf einem IIS-Server bereitstellen, werden möglicherweise 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 . Das Entfernen von Roslyn sollte die Funktionalität Ihres Codes nicht beeinträchtigen. Es hat gut funktioniert für mich und einige andere Projekte (C # 4.5.2), an denen ich gearbeitet habe.

Führen Sie die folgenden Schritte aus:

1. Entfernen Sie die folgenden Nuget-Pakete mithilfe der unten gezeigten Befehlszeile ( oder verwenden Sie die GUI des Nuget-Paket-Managers, indem Sie mit der rechten Maustaste auf Root Project Solution klicken und diese entfernen ).

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

2. Entfernen Sie den folgenden Code aus Ihrer Web.Config-Datei und starten Sie IIS neu . ( Verwenden Sie diese Methode nur, wenn Schritt 1 Ihr Problem nicht löst. )

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

Befolgen Sie die Anweisungen dieser Antwort. Während es das vorliegende Problem löst, kann es zu einem späteren Zeitpunkt andere Probleme verursachen.

Ich habe das gleiche Problem. Anscheinend wurde der .NET-Compiler nicht in den geladen GAC. Was ich getan habe, um es zu lösen, war:

Geben Sie zunächst in der Paketmanager-Konsole Folgendes ein:

PM> Install-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Aus irgendeinem Grund haben die netten Herren von Microsoft beschlossen, es nicht für uns im GAC zu installieren. Sie können dies manuell tun, indem Sie die Eingabeaufforderung für Entwickler öffnen und Folgendes eingeben:

gacutil -i "C:\*PATH TO YOUR APP CODE*\bin\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.dll"

Fazit

Microsoft versucht, alle zu ermutigen, alles mit Nugets zu tun, was ohne die gelegentlichen Fehler, auf die Sie mit dem Nuget-System stoßen, in Ordnung sein könnte. Versuchen Sie, dasselbe Projekt für verschiedene Lösungen zu verwenden, und aktualisieren Sie versehentlich (oder nicht) eines der vielen Nugets, die für eines von ihnen verwendet werden. Wenn Sie Pech haben, werden Sie sehen, was ich meine, wenn Sie versuchen, die andere Lösung zu erstellen. Andererseits kann das Einfügen von Dateien in den GAC auch zukünftige Probleme verursachen, da die Benutzer häufig vergessen, was sie dort ablegen, und beim Einrichten neuer Umgebungen vergessen, diese Dateien einzuschließen. Eine andere mögliche Lösung besteht darin, die Dateien in einem zentralen Ordner für DLLs von Drittanbietern abzulegen (obwohl es seltsam ist, den Compiler als Drittanbieter aufzurufen), was beim Einrichten neuer Umgebungen zu Problemen mit fehlerhaften Referenzen führt. Wenn Sie die DLL auf dem GAC installieren möchten, Seien Sie vorsichtig und denken Sie daran, dass Sie dies getan haben. Wenn Sie dies nicht tun, laden Sie das Nuget für jedes Projekt erneut herunter und tragen Sie alle lästigen Fehler, die dadurch verursacht werden (zumindest früher, als ich es endlich satt hatte und die Dateien einfach in das GAC legte). Beide Ansätze können Kopfschmerzen verursachen und Probleme verursachen. Es ist nur eine Frage der Probleme, mit denen Sie sich am liebsten befassen. Microsoft empfiehlt, das Nuget-System zu verwenden. Im Allgemeinen ist es besser, sie anzuhören als einen unbekannten Programmierer in SO, es sei denn, Sie haben das Nuget-System vollständig satt und haben sich lange genug mit dem GAC befasst, damit es eine bessere Alternative darstellt für dich. Laden Sie das Nuget für jedes Projekt erneut herunter und tragen Sie alle lästigen Fehler, die dadurch verursacht werden (zumindest früher, als ich es endlich satt hatte und die Dateien einfach in das GAC legte). Beide Ansätze können Kopfschmerzen verursachen und Probleme verursachen. Es ist nur eine Frage der Probleme, mit denen Sie sich am liebsten befassen. Microsoft empfiehlt, das Nuget-System zu verwenden. Im Allgemeinen ist es besser, sie anzuhören als einen unbekannten Programmierer in SO, es sei denn, Sie haben das Nuget-System vollständig satt und haben sich lange genug mit dem GAC befasst, damit es eine bessere Alternative darstellt für dich. Laden Sie das Nuget für jedes Projekt erneut herunter und tragen Sie alle lästigen Fehler, die dadurch verursacht werden (zumindest früher, als ich es endlich satt hatte und die Dateien einfach in das GAC legte). Beide Ansätze können Kopfschmerzen verursachen und Probleme verursachen. Es ist nur eine Frage der Probleme, mit denen Sie sich am liebsten befassen. Microsoft empfiehlt, das Nuget-System zu verwenden. Im Allgemeinen ist es besser, sie anzuhören als einen unbekannten Programmierer in SO, es sei denn, Sie haben das Nuget-System vollständig satt und haben sich lange genug mit dem GAC befasst, damit es eine bessere Alternative darstellt für dich.

Fügen Sie einfach das nächste Nuget-Paket zu Ihrem Projekt hinzu - Microsoft.CodeDom.Providers.DotNetCompilerPlatform.

Hatte das gleiche Problem.

Ich habe das gleiche Problem, dass meine App in Vs2013 funktioniert hat, aber nach dem Update auf Vs2015 wird der Fehler angezeigt.

1. Klicken Sie in Vs2015 mit der rechten Maustaste auf den Ordner "Referenzen" des Projekts, um NuGet Package Manager zu öffnen
2. Suchen Sie auf der Registerkarte Durchsuchen nach "DotNetCompilerPlatform" und installieren Sie die Bibliothek "Microsoft.CodeDom.Providers.DotNetCompilerPlatform"

Ich weiß, dass es ein alter Thread ist, aber ich möchte auf das mögliche Versionsproblem von DotNetCompilerPlatform.dll hinweisen, f. Ex. nach einem Update. Bitte überprüfen Sie, ob sich die neu generierte Datei Web.config von Ihrer freigegebenen Datei web.config unterscheidet, insbesondere der Teil system.codedom. In meinem Fall war es die Versionsänderung von 1.0.7 auf 1.0.8. Die neue DLL wurde bereits auf den Server kopiert, aber ich habe die alte web.config nicht geändert (mit einigen speziellen Servereinstellungen):

<pre>
  <system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.8.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.8.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" />
    </compilers>
  </system.codedom>
</pre>

Nachdem ich die beiden Zeilen aktualisiert habe, ist der Fehler verschwunden.

Gemäß Ihren Repro-Schritten habe ich angenommen, dass das Ändern des Ausgabepfads in der Anwendungseigenschaft Ihre einzige Änderung war, nachdem Sie die Anwendung erstellt haben. Diese Änderung bewirkt lediglich, dass Visual Studio angewiesen wird, die Ausgabe-Assemblys von MSBuild in den neuen Ordner zu verschieben. Zur Laufzeit hätte ASP.Net jedoch keine Ahnung, dass Assemblys aus diesem neuen Ordner anstelle des Ordners \ bin geladen werden sollten.

Diese Antwort zeigt, wie Sie das Build-Ausgabeverzeichnis einer WebApi-Anwendung ändern können. Um genau den gleichen Fehler zu erhalten, der in diesem Beitrag angezeigt wird, müssen Sie den gesamten Abschnitt <system.codedom> in web.config auskommentieren. Anschließend können Sie den Anweisungen zum Ändern des Ausgabepfads folgen.

Nachdem Sie Ihre Bewerbungsarbeit erhalten haben, können Sie den Abschnitt <system.codedom> auskommentieren. Wenn Sie in Ihrer Anwendung überhaupt keine neue C # 6-Syntax verwenden, können Sie die Microsoft.CodeDom.Providers.DotNetCompilerPlatform von Ihrer Anwendung deinstallieren. Andernfalls möchten Sie möglicherweise die folgende Befehlszeile in Ihr Post-Build-Ereignis einfügen:

xcopy /Q /Y "$(TargetDir)roslyn\*.*" "$(TargetDir)..\roslyn\"

Der neue CodeDom-Anbieter sucht immer nach dem Ordner "\ roslyn" in \ bin. Der obige Befehl dient als Problemumgehung und kopiert den Ordner \ roslyn aus Ihrem neuen Ausgabeordner nach \ bin.

In meinen Experimenten hat das Veröffentlichungstool von Visual Studio die Ausgabebaugruppen jedoch unabhängig von meiner Einstellung für den Ausgabepfad im Ordner \ bin am Bereitstellungsort veröffentlicht. Ich denke, Ihre Anwendung sollte noch bei der tatsächlichen Bereitstellung funktionieren.

Einfacher Weg - Projekt> NuGet-Pakete verwalten ...> Durchsuchen (Registerkarte)> Stellen Sie in der Sucheingabe Folgendes ein: Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Sie können diesen Compiler installieren oder aktualisieren oder deinstallieren und installieren

Eine andere mögliche Lösung:

Starten Sie Ihre Visual Studio-Instanz mit Administratorrechten neu

Es wurde nach der Veröffentlichung auf dem Produktionsserver gestoppt. Der Grund, warum dieser Fehler angezeigt wurde, war, dass er in einem Unterordner bereitgestellt wurde . In IIS habe ich rechts auf den Unterordner geklickt und "In Anwendung konvertieren" ausgeführt und danach hat es funktioniert.

In meinem Fall geschah dies, als ich die Berechtigung des Anwendungsordners änderte und das Konto IIS_IUSRS entfernt wurde. Nachdem ich IIS_IUSRS (IIS Manager-> YourWebApp -> Berechtigung bearbeiten -> IIS_IUSRS hinzufügen) erneut zum Anwendungsordner hinzugefügt habe und es funktioniert hat.

So habe ich es gelöst :

1. Löschte den binOrdner im Projektverzeichnis.
2. Klicken Sie auf Build Solution. In VS2017 ( Als Administrator ausführen)> Erstellen> Lösung erstellen .

Wenn Sie git verwenden, ignorieren Sie wahrscheinlich die DLL im Commit

Ich hatte eine Reihe von Projekten in der Lösung und das Webprojekt (Problem mit diesem Fehler) wurde nicht als StartUp-Projekt festgelegt. Ich habe dieses Webprojekt als StartUp-Projekt festgelegt und auf den Menüpunkt "Debug" -> "Debugging starten" geklickt und es hat funktioniert. Ich habe mit dem Debuggen aufgehört und es dann erneut versucht und jetzt funktioniert es wieder. Seltsam.

Dann kam das Problem zurück. Ich habe beide deinstalliert Microsoft.CodeDom.Providers.DotNetCompilerPlatformund Uninstall-package Microsoft.Net.Compilersaber keine Hilfe. Dann installiert - keine Hilfe. Projekt gereinigt und keine Hilfe gebaut. Neustart des Servers keine Hilfe. Dann bemerkte ich, dass das Projekt nicht das neueste benötigte, das derzeit 1.0.5 ist, sondern 1.0.3, da dies der Fehler war, konnte die 1.0.3-Version nicht geladen werden. Also habe ich stattdessen diese DLL-Version installiert und jetzt funktioniert es.

ASP.NET durchsucht bin/debugoder Unterordner unter bin nicht nach Assemblys wie andere Arten von Anwendungen. Mit der folgenden Konfiguration können Sie die Laufzeit anweisen, an einem anderen Ort zu suchen:

<configuration>
   <runtime>   
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="bin;bin\Debug;bin\Release"/>
      </assemblyBinding>
   </runtime>   
</configuration>

Sie sollten die Pakete "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" und "Microsoft.Net.Compilers" in Ihrem Projekt aktualisieren.

In meinem Fall wurde der Fehler angezeigt, als ich meine Webanwendung in 4.5.2 und die referenzierten Klassenbibliotheken in 4.6.1 hatte. Als ich die Webanwendung auf die Version 4.5.2 aktualisiert habe, ist der Fehler behoben.

Ich habe diesen Fehler erhalten, weil mein Anwendungspoolbenutzer auf ApplicationPoolIdentity festgelegt wurde. Ich habe es in ein Benutzer- / Dienstkonto geändert, das Zugriff auf den Ordner hat, und der Fehler ist verschwunden.

Hier sind meine Ergebnisse. Ich war heute Morgen auch mit diesem Problem konfrontiert. Ich habe gerade meinen aktuellen Benutzer zum Anwendungspool hinzugefügt, auf dem die Anwendung ausgeführt wurde.

Schritte:

1. Öffnen Sie IIS

2. Klicken Sie auf Anwendungspool

3. Wählen Sie Ihren Anwendungspool aus, für den Sie ein Problem haben

4. Rechtsklick -> Erweiterte Einstellungen

5. Klicken Sie auf das Dreipunktsymbol neben der Identität

6. Wählen Sie nun ein benutzerdefiniertes Konto

7. Geben Sie Ihren PC-Benutzernamen und Ihr Passwort an

8. sparen

Aktualisieren Sie Ihre Anwendung .. und es wird funktionieren. Beim Zugriff auf die DLL gab es ein Sicherheitsproblem.

Deinstallieren Sie das Paket einfach über den folgenden Befehl von der Paketmanagerkonsole

PM> Deinstallationspaket Microsoft.CodeDom.Providers.DotNetCompilerPlatform

PM> Microsoft.Net.Compilers deinstallieren

und installieren Sie es dann erneut über den Nuget Manager

Wenn Sie das Microsoft.CodeDom.Providers.DotNetCompilerPlatformPaket kürzlich installiert oder aktualisiert haben , überprüfen Sie, ob die Versionen dieses Pakets, auf die in Ihrem Projekt verwiesen wird, auf die richtige und gleiche Version dieses Pakets verweisen:

• In ProjectName.csproj, sicherzustellen , dass ein <Import>Tag für Microsoft.CodeDom.Providers.DotNetCompilerPlatformvorhanden ist , und auf die richtige Version.

• In ProjectName.csproj, sicherzustellen , dass ein <Reference>Tag für Microsoft.CodeDom.Providers.DotNetCompilerPlatformvorhanden ist, und verweist auf die richtige Version sowohl im IncludeAttribute und das Kind <HintPath>.

• Stellen Sie in diesem Projekt web.configsicher, dass das <system.codedom>Tag vorhanden ist und dass seine untergeordneten <compiler>Tags dieselbe Version in ihrem typeAttribut haben.

Aus irgendeinem Grund, in meinem Fall ein Upgrade dieses Pakets von 1.0.5 bis 1.0.8 verursachte den <Reference>Tag in der .csprojseine haben Include1.0 zeigt auf die alte Version. 5 .0 (die ich nach dem Upgrade des Pakets gelöscht hatte), aber alles andere zeigte auf die neue und korrekte Version 1.0. 8 .0.

Stellen Sie sicher, dass Ihr Projekt vollständig erstellt wurde!

Klicken Sie auf die Registerkarte "Ausgabe" und stellen Sie sicher, dass Sie Folgendes nicht haben:

========== Alle neu erstellen: 14 erfolgreich, 1 fehlgeschlagen, 0 übersprungen =========

Öffnen Sie Ihren binOrdner und prüfen Sie, ob er aktuell ist.

Ich hatte eine ganze Reihe von Typoskriptfehlern, die ich zuerst ignorierte, wobei ich vergaß, dass sie den Build brachen und dazu führten, dass keine DLLs kopiert wurden.

Fügen Sie einen Verweis auf die CppCodeProvider-Assembly hinzu.

In meinem Fall wurde mein Webprojekt nicht richtig geladen (es zeigte, dass das Projekt nicht verfügbar war), dann musste ich mein Webprojekt neu laden, nachdem ich mein Visual Studio im Admin-Modus geöffnet hatte, dann funktionierte alles einwandfrei.

Ich hatte nur das gleiche Problem, weil ich den Projektspeicherort verschoben habe und einfach das virtuelle Verzeichnis neu erstellen musste.

Die Ausnahme, auf die wir gestoßen sind, war nicht auf dem lokalen, sondern auf dem Remote-Server. Das Azure CI hat sie aus dem Paketordner gelesen, aber die oben genannten Compiler-Versionen wurden nicht gefunden.

Um dies zu beheben, haben wir die Projektdatei so geändert, dass sie ungefähr so ​​aussieht

Es verweist nicht auf eines der Pakete, die hier direkt auf die Umgebungsvariablen verweisen.

Dies hat das Problem behoben. In unseren Fällen verwenden wir jedoch keine Pakete direkt aus "package.config", sondern haben einen separaten Ordner, um die Versionsintegrität zwischen den Teams aufrechtzuerhalten.

Gehen Sie vom Startbefehl zu inetmgr. Wählen Sie in der IIS-Manager-Konsole den Anwendungsordner unter Standardwebsite aus, klicken Sie mit der rechten Maustaste auf diesen Ordner und konvertieren Sie ihn in eine Anwendung. Führen Sie die .asmx-Datei durch Aktivieren aus. Das Problem wurde behoben

Überprüfen Sie, ob der BINOrdner vollständig hochgeladen wurde oder in den Dateien fehlt.

In Bezug auf diesen Fehler habe ich versucht:

• Projekt reinigen und neu aufbauen
• Projekt entladen und neu laden
• Ändern des Ziel-Frameworks
• Ändern des Ausgabepfads
• Hinzufügen von Nuggets zum GAC
• Löschen Sie die Pakete uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform uninstall-package Microsoft.Net.Compilersund installieren Sie sie erneut.

Obwohl dies alles gültige Lösungen zu sein scheinen, konnte ich nur neue Fehler generieren und am Ende scheint der Fehler angezeigt zu werden, wenn bestimmte Referenzen / Nugets fehlen.

In meinem Fall hatte ich kürzlich Microsoft Office neu installiert und verwies auf Assemblys wie Microsoft.Office.Core. Die neue Installation schien nicht die erforderlichen Pakete zu enthalten, weshalb meine Lösung nicht korrekt erstellt werden konnte.

Ich konnte dieses Problem lösen, indem ich meinen Code so weit überarbeitete, dass ich nicht mehr auf Microsoft.Office verweisen musste, sondern es hätte lösen können, indem ich die erforderlichen Pakete nachgeschlagen und entsprechend installiert hätte.

Scheint eine unklare Fehlermeldung von Visual Studio zu sein.

Wenn Sie an einem Projekt gearbeitet haben und dies gerade als Fehler aufgetreten ist. Starten Sie Ihren Computer (oder Server in meinem Fall) neu, dies hat das Problem für mich behoben.