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

Wenn Ihr Projekt Roslyn-Referenzen enthält und Sie es auf einem IIS -Server bereitstellen , erhalten Sie möglicherweise unerwünschte Fehler auf der Website, da viele Hosting-Provider ihre Server noch nicht aktualisiert haben und daher nicht unterstütze Roslyn.

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 Sie können die GUI des Nuget Package Managers verwenden, indem Sie mit der rechten Maustaste auf Root Project Solution klicken und sie 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>
   

Beachten Sie die Hinweise dieser Antwort. Es löst zwar das anstehende Problem, kann jedoch zu einem späteren Zeitpunkt mit Sicherheit zu unterschiedlichen Problemen führen.

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

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

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

Nun, 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 Developer-Eingabeaufforderung ö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 Nuggets zu tun, was ohne die gelegentlichen Fehler, die Sie mit dem Nuggetsystem haben, gut ist. Versuchen Sie dasselbe Projekt für verschiedene Lösungen zu verwenden. Aktualisieren Sie versehentlich (oder nicht) eines der vielen Nugets, die es für eine davon verwendet. Wenn Sie Pech haben, werden Sie feststellen, was ich meine, wenn Sie versuchen, die andere Lösung zu erstellen. Andererseits kann das Einfügen von Dateien in das GAC zukünftige Probleme verursachen, da die Benutzer dazu neigen, ihre Inhalte dort zu vergessen, und beim Einrichten neuer Umgebungen vergessen sie, 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 merkwürdig ist, den Compiler als Drittanbieter zu bezeichnen), was beim Einrichten neuer Umgebungen zu Problemen mit fehlerhaften Verweisen führt. Wenn Sie sich entscheiden, die DLL im GAC zu installieren, 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 ärgerlichen Fehler, die von diesem verursacht werden (zumindest, wenn ich es endlich satt habe und die Dateien einfach in das GAC gestellt habe). Beide Ansätze können Ihnen Kopfschmerzen bereiten und Probleme verursachen. Es ist nur eine Frage, mit welchen Problemen Sie sich beschäftigen möchten. Microsoft empfiehlt, das Nuget-System zu verwenden, und im Allgemeinen ist es besser, auf sie zu hören als auf einen unbekannten Programmierer in SO, es sei denn, Sie haben das Nuget-System völlig satt und haben sich lange genug mit dem GAC beschäftigt, um eine bessere Alternative zu sein 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 funktionierte, aber nach dem Update auf Vs2015 den Fehler bekam.

1. Klicken Sie in der Version 2017 mit der rechten Maustaste auf den Ordner "Referenzen" des Projekts, um den 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ß, es ist ein alter Thread, aber ich möchte auf die mögliche Version der DotNetCompilerPlatform.dll hinweisen, f. Ex. nach einem Update. Bitte überprüfen Sie, ob die neu generierte Datei "Web.config" sich von der veröffentlichten Datei "web.config" unterscheidet, insbesondere den Teil "system.codedom". In meinem Fall war es der Versionswechsel 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.

Ihren Repro-Schritten zufolge nahm ich an, dass das Ändern des Ausgabepfads in der Eigenschaft der Anwendung Ihre einzige Änderung war, nachdem Sie die Anwendung erstellt haben. Das einzige, was diese Änderung bewirkt, ist, dass Visual Studio die Ausgabebaugruppen von MSBuild in den neuen Ordner ablegt. Zur Laufzeit wusste ASP.Net jedoch nicht, dass es Assemblys aus diesem neuen Ordner anstelle des Ordners\bin laden sollte. 

Diese Antwort zeigt, wie das Build-Ausgabeverzeichnis einer WebApi-Anwendung geändert werden kann. Um genau dieselbe Fehlermeldung zu erhalten, die in diesem Beitrag angezeigt wird, müssen Sie den gesamten Abschnitt <system.codedom> in web.config auskommentieren. Dann können Sie den Anweisungen folgen, um den Ausgabepfad zu ändern.

Nachdem Sie Ihre Bewerbungsarbeiten erhalten haben, können Sie den Abschnitt <system.codedom> unkommentieren. Wenn Sie in Ihrer Anwendung überhaupt keine neue C # 6-Syntax verwenden, können Sie Microsoft.CodeDom.Providers.DotNetCompilerPlatform aus Ihrer Anwendung deinstallieren. Andernfalls möchten Sie möglicherweise die folgende Befehlszeile in Ihr Postbuild-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\roslyn-Ordner aus Ihrem neuen Ausgabeordner nach\bin. 

In meinen Experimenten veröffentlichte das Veröffentlichungstool von Visual Studio jedoch die Ausgabeassemblys im Ordner\bin am Bereitstellungsspeicherort, unabhängig von meiner Ausgabepfadeinstellung. Ich denke, Ihre Anwendung sollte noch mit der tatsächlichen Bereitstellung funktionieren.

Einfacher Weg - Project> NuGet-Pakete verwalten ...> Durchsuchen (Registerkarte)> in der Eingabe für die Suche Folgendes festlegen: Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Sie können diesen Compiler installieren, aktualisieren oder deinstallieren

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

Eine andere mögliche Lösung könnte sein:

Starten Sie Ihre Visual Studio-Instanz mit Administrator Rights neu! 

Es wurde nach der Veröffentlichung auf dem Produktionsserver angehalten. Der Grund, warum dieser Fehler angezeigt wurde, war, dass er in einem sub - Ordner bereitgestellt wurde. In IIS habe ich rechts auf den Unterordner geklickt und "In Anwendung konvertieren" ausgewählt. Danach funktionierte es.

Wenn Sie das Microsoft.CodeDom.Providers.DotNetCompilerPlatform-Paket kürzlich installiert oder aktualisiert haben, überprüfen Sie noch einmal, ob die in Ihrem Projekt referenzierten Versionen dieses Pakets auf die richtige und dieselbe Version dieses Pakets verweisen:

• Stellen Sie in ProjectName.csproj sicher, dass ein <Import>-Tag für Microsoft.CodeDom.Providers.DotNetCompilerPlatform vorhanden ist und auf die richtige Version verweist.

• Stellen Sie in ProjectName.csproj sicher, dass ein <Reference>-Tag für Microsoft.CodeDom.Providers.DotNetCompilerPlatform vorhanden ist und auf die richtige Version verweist, und zwar sowohl im Include-Attribut als auch im untergeordneten <HintPath>.

• Stellen Sie im web.config des Projekts sicher, dass das <system.codedom>-Tag vorhanden ist und dass die untergeordneten <compiler>-Tags die gleiche Version in ihrem type-Attribut haben.

Aus irgendeinem Grund führte in meinem Fall ein Upgrade dieses Pakets von 1.0.5 auf 1.0.8 dazu, dass das <Reference>-Tag im .csproj auf Include auf die alte Version 1.0. 5 . 0 (die ich danach gelöscht hatte) verweist Aktualisierung des Pakets), aber alles andere zeigte auf die neue und korrekte Version 1.0. 8 . 0.

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

ASP.NET durchsucht nicht bin/debug oder andere Unterordner unter bin nach Baugruppen wie andere Arten von Anwendungen. Sie können die Laufzeitumgebung anweisen, an einer anderen Stelle mit der folgenden Konfiguration zu suchen:

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

Dann kam das Problem zurück. Ich habe sowohl Microsoft.CodeDom.Providers.DotNetCompilerPlatform als auch Uninstall-Paket Microsoft.Net.Compilers deinstalliert, jedoch 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, aber 1.0.3, da der Fehler die Version 1.0.3 nicht laden konnte. Also habe ich stattdessen die DLL-Version installiert und jetzt funktioniert es.

Hier ist, wie ich gelöst es: 

1. Der bin-Ordner wurde im Projektverzeichnis gelöscht.
2. Klicken Sie auf Build Solution. In VS2017 (Als Administrator ausführen)> Erstellen> Projektmappe erstellen}.

Diese Fehlermeldung wurde angezeigt, weil der 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 Erkenntnisse. Ich bin auch heute Morgen 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 erhalten

4. Rechtsklick -> Erweiterte Einstellungen

5. Klicken Sie auf das Drei-Punkt-Symbol neben der Identität

6. Wählen Sie nun das benutzerdefinierte Konto aus

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

8. Sparen

Aktualisieren Sie Ihre Anwendung .. und es beginnt zu arbeiten. Es gab einige Sicherheitsprobleme beim Zugriff auf die DLL.

Ich hatte mehrere Projekte 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 das Debuggen beendet und es erneut versucht. Jetzt funktioniert es wieder. Seltsam.

In meinem Fall erhielt ich den Fehler, als ich meine Webanwendung in 4.5.2 und die referenzierten Klassenbibliotheken in 4.6.1 hatte. Wenn ich die Webanwendung auf Version 4.5.2 aktualisiere, ging der Fehler weg.

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

Prüfen Sie, ob der Ordner BIN vollständig hochgeladen wurde oder in den Dateien fehlt.

Stellen Sie sicher, dass Ihr Projekt vollständig aufgebaut ist!

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

=========== Alles neu aufbauen: 14 erfolgreich, 1 fehlgeschlagen, 0 übersprungen =========

Öffnen Sie Ihren bin-Ordner und prüfen Sie, ob er auf dem neuesten Stand ist.

Ich hatte eine ganze Reihe von TypeScript-Fehlern, die ich zuerst ignorierte, wobei ich vergaß, dass sie den Build kaputt machten und dazu führte, dass keine DLLs kopiert wurden.

Ich hatte gerade das gleiche Problem und es war, weil ich den Projektstandort verschoben habe und das virtuelle Verzeichnis einfach neu erstellen musste.

In Bezug auf diesen Fehler habe ich versucht:

• Projekt bereinigen und neu aufbauen
• Projekt entladen und neu laden
• Ändern des Zielframeworks
• Ändern des Ausgabepfads
• Hinzufügen von Nuggets zum GAC
• Löschen der Pakete uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatformuninstall-package Microsoft.Net.Compilers und erneutes Installieren.

Während dies alles gültige Lösungen zu sein scheinen, ich konnte nur neue Fehler generieren und am Ende scheint der Fehler in der Lage zu sein, anzuzeigen, 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, was dazu führte, dass meine Lösung nicht richtig erstellt werden konnte.

Ich konnte dieses Problem beheben, indem ich meinen Code so weit überarbeitete, dass ich nicht mehr auf Microsoft.Office verweisen musste, sondern indem ich die erforderlichen Pakete nachschlug und sie entsprechend installierte.

Scheint wie eine unklare Fehlermeldung von Visual Studio.

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

Gehen Sie vom Startbefehl zu Inetmgr .__In der IIS Manager-Konsole Wählen Sie den Anwendungsordner unter Standardwebsite aus Klicken Sie mit der rechten Maustaste auf diesen Ordner und dann In Anwendung konvertieren die .asmx-Datei durch Aktivieren von Sie hat das Problem gelöst

deinstallieren Sie einfach das Paket von der Package Manager Console aus

PM> Deinstallationspaket Microsoft.CodeDom.Providers.DotNetCompilerPlatform

PM> Deinstallationspaket Microsoft.Net.Compilers

und installieren Sie es erneut vom Nuget-Manager  

Die Ausnahme, die wir hatten, war nicht auf dem lokalen Server, sondern auf dem Remote-Server, das Azure-CI las es aus dem Paketordner, aber die oben genannten Compilerversionen wurden nicht gefunden.

Um dieses Problem zu beheben, haben wir die Projektdatei so geändert, dass sie in etwa ____ ist.

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

Das Problem wurde behoben. In unseren Fällen verwenden wir jedoch keine Pakete direkt aus "package.config". Stattdessen verfügen wir über einen separaten Ordner, um die Versionsintegrität zwischen den Teams aufrechtzuerhalten.