Nie można zlokalizować typu dostawcy CodeDom „Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider”

To projekt WebApi wykorzystujący VS2015.

Krok do reprodukcji:

1. Utwórz pusty projekt WebApi
2. Zmień ścieżkę wyjściową kompilacji z „bin \” na „bin \ Debug \”
3. Biegać

Wszystko działa idealnie, dopóki nie zmieniłem ścieżki Build Output z „bin \” na „bin \ Debug \”. W rzeczywistości żadna ścieżka wyjściowa inna niż „bin \” nie będzie działać.

Jedną małą dodatkową rzeczą jest to, że posiadanie innej ścieżki wyjściowej do dowolnego miejsca działałoby tak długo, jak zostawiłem kompilację w "bin \".

Proszę o pomoc w dostarczeniu rozwiązania tego problemu. Myślę, że to będzie kosztować problem przy rzeczywistym wdrożeniu.

Jeśli Twój projekt ma odwołania do Roslyn i wdrażasz go na serwerze IIS , możesz otrzymać niechciane błędy w witrynie sieci Web, ponieważ wielu dostawców hostingu nadal nie zaktualizowało swoich serwerów i dlatego nie obsługuje Roslyn.

Aby rozwiązać ten problem, musisz usunąć kompilator Roslyn z szablonu projektu . Usunięcie Roslyn nie powinno wpłynąć na funkcjonalność twojego kodu. Działało dobrze dla mnie i kilku innych projektów (C # 4.5.2), nad którymi pracowałem.

Wykonaj następujące kroki:

1. Usuń z następujących pakietów Nuget za pomocą wiersza poleceń pokazanego poniżej ( lub możesz użyć GUI menedżera pakietów Nuget, klikając prawym przyciskiem myszy na rozwiązanie projektu głównego i usuwając je ).

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

2. Usuń następujący kod z pliku Web.Config i uruchom ponownie usługi IIS . ( Użyj tej metody tylko wtedy, gdy krok 1 nie rozwiązuje problemu ).

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

Uważaj, aby postępować zgodnie z radą zawartą w tej odpowiedzi. Chociaż rozwiązuje problem, może powodować inne problemy w późniejszym terminie.

Mam ten sam problem. Najwyraźniej kompilator .NET nie został załadowany do GAC. Oto co zrobiłem, aby to rozwiązać:

Najpierw w konsoli menedżera pakietów wpisz:

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

Z jakiegoś powodu mili panowie w Microsoft zdecydowali się nie instalować go za nas w GAC. Możesz to zrobić ręcznie, otwierając wiersz polecenia programisty i wpisując:

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

Wniosek

Microsoft stara się zachęcić wszystkich do robienia wszystkiego z nugetami, co może być w porządku bez sporadycznych błędów, które napotykasz w systemie nuget. Spróbuj użyć tego samego projektu w różnych rozwiązaniach, przypadkowo (lub nie) zaktualizuj jeden z wielu nugetów, których używa na jednym z nich, a jeśli nie masz szczęścia, zobaczysz, co mam na myśli, próbując zbudować drugie rozwiązanie. Z drugiej strony, umieszczanie plików w GAC może również powodować problemy w przyszłości, ponieważ ludzie mają tendencję do zapominania, co tam umieścili, a następnie podczas konfigurowania nowych środowisk zapominają o dołączeniu tych plików. Innym możliwym rozwiązaniem jest umieszczenie plików w folderze centralnym dla bibliotek DLL innych firm (nawet jeśli dziwne jest nazywanie kompilatora strony trzeciej), co stwarza problemy z uszkodzonymi referencjami podczas konfigurowania nowych środowisk. Jeśli zdecydujesz się zainstalować dll na GAC, zachowaj ostrożność i pamiętaj, że to zrobiłeś. Jeśli tego nie zrobisz, pobierz ponownie nuget dla każdego projektu i ponieść wszystkie irytujące błędy, które są przez niego spowodowane (przynajmniej zdarzało się, gdy w końcu miałem tego dość i po prostu umieściłem pliki w GAC). Oba podejścia mogą przyprawiać Cię o bóle głowy i stwarzać problemy, to tylko kwestia tego, z którymi problemami wolisz sobie radzić. Microsoft zaleca korzystanie z systemu nuget i generalnie lepiej ich słuchać niż nieznanego programisty w SO, chyba że masz już dość systemu nuget i korzystałeś z GAC wystarczająco długo, aby był lepszą alternatywą dla Ciebie. pobierz nuget dla każdego projektu ponownie i ponieść wszystkie irytujące błędy przez niego spowodowane (przynajmniej zdarzało się, gdy w końcu miałem go dość i po prostu umieściłem pliki w GAC). Oba podejścia mogą przyprawiać Cię o bóle głowy i stwarzać problemy, to tylko kwestia tego, z którymi problemami wolisz sobie radzić. Microsoft zaleca korzystanie z systemu nuget i generalnie lepiej ich słuchać niż nieznanego programisty w SO, chyba że masz już dość systemu nuget i korzystałeś z GAC wystarczająco długo, aby był lepszą alternatywą dla Ciebie. pobierz nuget dla każdego projektu ponownie i ponieść wszystkie irytujące błędy przez niego spowodowane (przynajmniej zdarzało się, gdy w końcu miałem go dość i po prostu umieściłem pliki w GAC). Oba podejścia mogą przyprawiać Cię o bóle głowy i powodować problemy, to tylko kwestia tego, z którymi problemami wolisz sobie radzić. Microsoft zaleca korzystanie z systemu nuget i generalnie lepiej ich słuchać niż nieznanego programisty w SO, chyba że masz już dość systemu nuget i używałeś do czynienia z GAC wystarczająco długo, aby był on lepszą alternatywą dla Ciebie.

Po prostu dodaj następny pakiet NuGet do projektu - Microsoft.CodeDom.Providers.DotNetCompilerPlatform.

Miałem ten sam problem.

Mam ten sam problem, że moja aplikacja działała w Vs2013, ale pojawia się błąd po aktualizacji do Vs2015.

1. W wersji 2015 kliknij prawym przyciskiem myszy folder odwołania projektu, aby otworzyć Menedżera pakietów NuGet
2. Na karcie Przeglądaj wyszukaj „DotNetCompilerPlatform” i zainstaluj bibliotekę „Microsoft.CodeDom.Providers.DotNetCompilerPlatform”

Wiem, że to stary wątek, ale chciałbym wskazać możliwy problem z wersją DotNetCompilerPlatform.dll, f. dawny. po aktualizacji. Sprawdź, czy nowo wygenerowany plik Web.config różni się od wydanego pliku web.config, w szczególności części system.codedom. W moim przypadku była to zmiana wersji z 1.0.7 na 1.0.8. Nowa biblioteka dll została już skopiowana na serwer, ale nie zmieniłem starego pliku web.config (z pewnymi specjalnymi ustawieniami serwera):

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

Po zaktualizowaniu dwóch linii błąd zniknął.

Zgodnie z twoimi powtórzeniami założyłem, że zmiana ścieżki wyjściowej we właściwości aplikacji była jedyną zmianą po utworzeniu aplikacji. Jedyną rzeczą, jaką robi ta zmiana, jest to, że nakazuje programowi Visual Studio umieszczenie zestawów wyjściowych programu MSBuild w nowym folderze. Jednak w czasie wykonywania ASP.Net nie miałby pojęcia, że ​​powinien ładować zestawy z tego nowego folderu zamiast z folderu \ bin.

Ta odpowiedź przedstawia sposób zmiany katalogu wyjściowego kompilacji aplikacji WebApi. Aby uzyskać dokładnie ten sam błąd pokazany w tym poście, musisz skomentować całą sekcję <system.codedom> w web.config. Następnie możesz postępować zgodnie z instrukcjami, aby zmienić ścieżkę wyjściową.

Po uruchomieniu aplikacji możesz odkomentować sekcję <system.codedom>. Jeśli w ogóle nie używasz nowej składni C # 6 w swojej aplikacji, możesz odinstalować Microsoft.CodeDom.Providers.DotNetCompilerPlatform ze swojej aplikacji; w przeciwnym razie możesz dodać następujący wiersz poleceń do zdarzenia po kompilacji,

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

Nowy dostawca CodeDom zawsze szuka folderu „\ roslyn” w katalogu \ bin. Powyższe polecenie działa jako obejście i kopiuje folder \ roslyn z nowego folderu wyjściowego do \ bin.

W moich eksperymentach narzędzie do publikowania programu Visual Studio opublikowało jednak zestawy wyjściowe w folderze \ bin w lokalizacji wdrożenia, niezależnie od ustawienia ścieżki wyjściowej. Myślę, że twoja aplikacja powinna nadal działać na rzeczywistym wdrożeniu.

Prosty sposób - Projekt> Zarządzaj pakietami NuGet ...> Przeglądaj (karta)> w danych wejściowych wyszukiwania ustaw to: Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Możesz zainstalować lub zaktualizować lub odinstalować i zainstalować ten kompilator

Inne możliwe rozwiązanie:

Uruchom ponownie wystąpienie programu Visual Studio z prawami administratora

Przestał działać po opublikowaniu na serwerze produkcyjnym. Powodem, pokazał mi ten błąd, ponieważ był wdrożony do sub folderu. W IIS kliknąłem bezpośrednio podfolder i wybrałem „Konwertuj na aplikację”, a potem zadziałało.

W moim przypadku stało się tak, gdy zmieniam uprawnienia do folderu aplikacji i konto IIS_IUSRS zostało usunięte. Po ponownym dodaniu IIS_IUSRS (IIS Manager-> YourWebApp -> Edit Permission -> Add IIS_IUSRS) do folderu aplikacji i jego działanie.

Oto jak to rozwiązałem :

1. Usunięto binfolder w katalogu projektu.
2. Kliknij Build Solution. W VS2017 (Uruchom jako administrator)> Kompiluj> Kompiluj rozwiązanie .

Jeśli używasz git, prawdopodobnie ignorujesz .dll w zatwierdzeniu

Miałem kilka projektów w rozwiązaniu, a projekt internetowy (problem z tym błędem) nie został ustawiony jako projekt StartUp. Ustawiłem ten projekt sieciowy jako projekt startowy i kliknąłem pozycję menu „Debuguj” -> „Rozpocznij debugowanie” i zadziałało. Przestałem debugować, a potem spróbowałem ponownie i teraz znowu działa. Dziwne.

Potem problem wrócił. I odinstalowane zarówno Microsoft.CodeDom.Providers.DotNetCompilerPlatforma Uninstall-package Microsoft.Net.Compilersjednak żadnej pomocy. Następnie zainstalowany - bez pomocy. Oczyszczono projekt i nie utworzono pomocy. Zrestartowałem serwer bez pomocy. Wtedy zauważyłem, że projekt nie potrzebuje najnowszego, który jest obecnie 1.0.5, ale 1.0.3, ponieważ to był błąd nie mógł załadować wersji 1.0.3. Zamiast tego zainstalowałem tę wersję dll i teraz działa.

ASP.NET nie przeszukuje bin/debugani żadnego podfolderu w koszu dla zestawów, tak jak robią to inne typy aplikacji. Możesz poinstruować środowisko wykonawcze, aby szukało w innym miejscu, używając następującej konfiguracji:

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

Należy zaktualizować pakiety „Microsoft.CodeDom.Providers.DotNetCompilerPlatform” i „Microsoft.Net.Compilers” w projekcie.

W moim przypadku wystąpił błąd, gdy miałem swoją aplikację internetową w wersji 4.5.2 i biblioteki klas, do których się odwołano, w wersji 4.6.1. Kiedy zaktualizowałem aplikację internetową do wersji 4.5.2, błąd zniknął.

Otrzymuję ten błąd, ponieważ dla mojego użytkownika puli aplikacji ustawiono ApplicationPoolIdentity. Zmieniłem go na konto użytkownika / usługi, które ma dostęp do folderu i błąd zniknął.

Oto moje ustalenia. Ja również stanąłem przed tym problemem dzisiaj rano. Właśnie dodałem mojego bieżącego użytkownika do puli aplikacji, na której była uruchomiona aplikacja.

Kroki:

1. Otwórz IIS

2. Kliknij pulę aplikacji

3. Wybierz pulę aplikacji, z którą masz problem

4. Kliknij prawym przyciskiem myszy -> ustawienia zaawansowane

5. Kliknij na trzy kropki obok ikony identiy

6. Teraz wybierz konto niestandardowe

7. Podaj nazwę użytkownika i hasło swojego komputera

8. Zapisać

Odśwież aplikację ... i zacznie działać. Wystąpił problem z bezpieczeństwem podczas uzyskiwania dostępu do biblioteki dll.

po prostu odinstaluj pakiet z konsoli menedżera pakietów za pomocą poniższego polecenia

PM> Odinstaluj pakiet Microsoft.CodeDom.Providers.DotNetCompilerPlatform

PM> Odinstaluj pakiet Microsoft.Net.Compilers

a następnie zainstaluj go ponownie z menedżera NuGet

Jeśli niedawno zainstalowałeś lub zaktualizowałeś Microsoft.CodeDom.Providers.DotNetCompilerPlatformpakiet, sprawdź dokładnie, czy wersje tego pakietu, do których odwołuje się Twój projekt, wskazują na poprawną i taką samą wersję tego pakietu:

• W programie ProjectName.csprojupewnij się, że istnieje <Import>tag dla Microsoft.CodeDom.Providers.DotNetCompilerPlatformi wskazuje poprawną wersję.

• W programie ProjectName.csprojupewnij się, że istnieje <Reference>znacznik dla Microsoft.CodeDom.Providers.DotNetCompilerPlatformi wskazuje prawidłową wersję, zarówno w Includeatrybucie, jak i w elemencie podrzędnym <HintPath>.

• W tym projekcie web.configupewnij się, że <system.codedom>tag jest obecny i że jego <compiler>tagi podrzędne mają tę samą wersję w swoim typeatrybucie.

Z jakiegoś powodu, w moim przypadku to uaktualnienie tego pakietu od 1.0.5 do 1.0.8 spowodował <Reference>tag w .csprojcelu mieć Includewskazując na starej wersji 1.0. 5 .0 (które usunąłem po aktualizacji pakietu), ale wszystko inne wskazywało na nową i poprawną wersję 1.0. 8 .0.

Upewnij się, że Twój projekt został w pełni zbudowany!

Kliknij kartę „Wyjście” i upewnij się, że nie masz czegoś takiego:

========== Przebuduj wszystko: 14 powiodło się, 1 nie powiodło się, 0 pominięto =========

Otwórz binfolder i sprawdź, czy jest aktualny.

Miałem całą masę błędów maszynopisu, które na początku zignorowałem, zapominając, że psują kompilację i prowadzą do tego, że nie ma skopiowanych bibliotek DLL.

Dodaj odwołanie do zestawu CppCodeProvider.

W moim przypadku mój projekt internetowy nie został poprawnie załadowany (pokazywał, że projekt jest niedostępny), a następnie musiałem ponownie załadować projekt internetowy po otwarciu mojego Visual Studio w trybie administratora i wszystko działało dobrze.

Miałem ten sam problem, ponieważ przeniosłem lokalizację projektu i po prostu musiałem odtworzyć katalog wirtualny.

Wyjątek, na który się natknęliśmy, nie znajdował się na serwerze lokalnym, ale na serwerze zdalnym, interfejs CI platformy Azure odczytywał go z folderu pakietów, ale nie znaleziono wspomnianych powyżej wersji kompilatora.

Aby to naprawić, zmodyfikowaliśmy plik projektu, aby wyglądał jak

Nie odwołuje się do żadnego z pakietów tutaj bezpośrednio odwołując się do zmiennych środowiskowych.

To rozwiązało problem, jednak w naszych przypadkach nie używamy pakietów bezpośrednio z pliku „package.config” zamiast tego mamy oddzielny folder, aby zachować integralność wersji w zespołach.

Przejdź do inetmgr z polecenia start W konsoli menedżera IIS wybierz folder aplikacji w obszarze Domyślna witryna sieci Web kliknij prawym przyciskiem myszy ten folder, a następnie Konwertuj na aplikację Uruchom plik .asmx, włączając Włączenie Rozwiązało problem

Sprawdź, czy BINfolder został przesłany w całości lub czy nie ma go w plikach.

Odnośnie tego błędu próbowałem:

• Czyszczenie i przebudowa projektu
• Rozładowanie i ponowne wczytanie projektu
• Modyfikowanie platformy docelowej
• Modyfikowanie ścieżki wyjściowej
• Dodawanie bryłek do GAC
• Usuwanie pakietów uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform uninstall-package Microsoft.Net.Compilersi ponowne ich instalowanie.

Chociaż wszystkie te wydają się być poprawnymi rozwiązaniami, byłem w stanie wygenerować tylko nowe błędy i ostatecznie błąd wydaje się być wyświetlany, gdy brakuje niektórych odniesień / elementów nugetów.

W moim przypadku niedawno ponownie zainstalowałem pakiet Microsoft Office i odwoływałem się do zestawów takich jak Microsoft.Office.Core. Nowa instalacja nie zawierała wymaganych pakietów, przez co moje rozwiązanie nie mogło zostać poprawnie zbudowane.

Udało mi się rozwiązać ten problem, przerabiając kod do punktu, w którym nie musiałem odwoływać się do Microsoft.Office, ale mogłem go rozwiązać, wyszukując wymagane pakiety i odpowiednio je instalując.

Wygląda na niejasny komunikat o błędzie z programu Visual Studio.

Jeśli pracowałeś nad projektem, a to właśnie pojawiło się jako błąd. Uruchom ponownie komputer (lub serwer w moim przypadku), to rozwiązało problem.