it-roy-ru.com

Тип поставщика CodeDom "Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider" не найден

Это проект WebApi, использующий VS2015.

Шаг для воспроизведения: 

  1. Создать пустой проект WebApi
  2. Измените путь вывода Build с «bin \» на «bin\Debug \»
  3. Бежать

 enter image description here

Все работает отлично, пока я не изменил путь вывода сборки с «bin \» на «bin\Debug \» На самом деле, любой путь вывода, кроме «bin \», работать не будет.

Еще одна небольшая дополнительная вещь заключается в том, что наличие другого пути вывода в любое место будет работать, пока я оставляю сборку в «bin \». 

Пожалуйста, помогите решить проблему. Я думаю, это будет стоить проблемы при фактическом развертывании.

108
cscmh99

Если в вашем проекте есть ссылки Roslyn и вы развертываете его на IIS сервере , вы можете получить нежелательные ошибки на сайте, так как многие хостинг-провайдеры все еще не обновили свои серверы и, следовательно, не делают этого. поддержать Рослин.

Чтобы решить эту проблему, вам нужно удалить компилятор Roslyn из шаблона проекта . Удаление Roslyn не должно влиять на функциональность вашего кода. Он работал нормально для меня и некоторых других проектов (C # 4.5.2), над которыми я работал.

Сделайте следующие шаги:

  1. Удалите из следующих пакетов Nuget с помощью командной строки, показанной ниже (или вы можете использовать графический интерфейс диспетчера пакетов Nuget, нажав правой кнопкой мыши на Root Project Solution и удалив их).

    PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
    PM> Uninstall-package Microsoft.Net.Compilers
    
  2. Удалите следующий код из файла Web.Config и перезапустите IIS . (Используйте этот метод, только если шаг 1 не решит вашу проблему.)

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

90
vibs2006

Будьте осторожны, следуя совету этого ответа. Хотя это решает проблему под рукой, это почти наверняка вызовет другие проблемы на более позднем этапе.

У меня та же проблема. По-видимому, компилятор .NET не был загружен в GAC. Что я сделал, чтобы решить это было:

Сначала в консоли диспетчера пакетов введите:

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

Теперь по какой-то причине джентльмены Nice в Microsoft решили не устанавливать его в GAC для нас. Вы можете сделать это вручную, открыв Командную строку разработчика и введя:

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

Заключение

Microsoft старается побудить всех делать все с помощью Nuget, что может быть хорошо без случайных ошибок, с которыми вы сталкиваетесь в системе Nuget. Попробуйте использовать один и тот же проект в разных решениях, случайно (или нет) обновить один из множества нюгетов, которые он использует для одного из них, и, если вам не повезет, вы поймете, что я имею в виду, когда попытаетесь построить другое решение. С другой стороны, размещение файлов в GAC также может вызвать будущие проблемы, поскольку люди, как правило, забывают, что они там помещают, а затем при настройке новых сред они забывают включить эти файлы. Другое возможное решение - поместить файлы в центральную папку для сторонних библиотек (хотя это странно называть компилятором сторонним), что создает проблемы с неработающими ссылками при настройке новых сред. Если вы решили установить dll в GAC, будьте осторожны и помните, что вы это сделали. Если вы этого не сделаете, загрузите nuget для каждого проекта еще раз и несите все досадные ошибки, вызванные им (по крайней мере, раньше случалось, когда мне это надоело, и я просто помещал файлы в GAC). Оба подхода могут вызвать у вас головную боль и создать проблемы, это просто вопрос о том, с какими проблемами вы предпочитаете иметь дело. Microsoft рекомендует использовать систему nuget, и, как правило, лучше слушать их, чем неизвестного программиста в SO, если вы не устали от системы nuget и не привыкли иметь дело с GAC достаточно долго, чтобы она стала лучшей альтернативой для тебя.

35
Yuval Perelman

Просто добавьте следующий пакет nuget в свой проект - Microsoft.CodeDom.Providers.DotNetCompilerPlatform.

Была такая же проблема.

25
Maris

У меня та же проблема, что мое приложение работало в Vs2013, но получало ошибку после обновления до Vs2015.

  1. В Vs2015 щелкните правой кнопкой мыши папку References проекта, чтобы открыть NuGet Package Manager.
  2. На вкладке «Обзор» найдите «DotNetCompilerPlatform» и установите lib «Microsoft.CodeDom.Providers.DotNetCompilerPlatform».
17
ninetiger

Я знаю, что это старая ветка, но я бы хотел указать на возможную проблему версии DotNetCompilerPlatform.dll, f. ех. после обновления. Проверьте, не отличается ли новый сгенерированный файл Web.config от вашего выпущенного файла web.config, в частности части system.codedom. В моем случае это было изменение версии с 1.0.7 на 1.0.8. Новая dll уже была скопирована на сервер, но я не изменил старый web.config (с некоторыми специальными настройками сервера):

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

После того, как я обновил две строки, ошибка исчезла.

14
user3266181

В соответствии с вашими действиями по воспроизведению, я предположил, что изменение пути вывода в свойстве приложения было вашим единственным изменением после создания приложения. Единственное, что делает это изменение, это говорит Visual Studio поместить выходные сборки MSBuild в новую папку. Однако во время выполнения ASP.Net не догадывается, что он должен загружать сборки из этой новой папки, а не из папки\bin. 

Этот ответ показывает способ изменения выходного каталога сборки приложения WebApi. Чтобы получить точно такую ​​же ошибку, что и в этом посте, вам нужно закомментировать весь раздел <system.codedom> в web.config. И тогда вы можете следовать инструкциям, чтобы изменить выходной путь.

После того, как вы получите работу приложения, вы можете раскомментировать раздел <system.codedom>. Если вы вообще не используете новый синтаксис C # 6 в своем приложении, вы можете удалить Microsoft.CodeDom.Providers.DotNetCompilerPlatform из вашего приложения; в противном случае вы можете добавить следующую командную строку в событие после сборки,

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

Новый провайдер CodeDom всегда ищет папку «\ roslyn» в\bin. Приведенная выше команда работает как обходной путь и копирует папку\roslyn из новой папки вывода в папку\bin. 

В моих экспериментах инструмент публикации Visual Studio, однако, публиковал выходные сборки в папке\bin в месте развертывания независимо от моего пути вывода. Я предполагаю, что ваше приложение все еще должно работать в реальном развертывании.

10
X-Mao

Простой способ - Project> Управление пакетами NuGet ...> Обзор (вкладка)> в поисковом вводе установите это: Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Вы можете установить или обновить или удалить и установить этот компилятор

 DotNetCompilerPlatform

7
Newred

В моем случае это произошло, когда я изменил разрешение папки приложения и учетная запись IIS_IUSRS была удалена. После того, как я повторно добавил IIS_IUSRS (IIS Manager-> YourWebApp -> Редактировать разрешение -> Добавить IIS_IUSRS) в папку приложения, оно заработало. 

4
TheRegister

Другое возможное решение может быть:

Перезапустите экземпляр Visual Studio с правами администратора

 enter image description here

3
Legends

Он остановился после публикации на рабочем сервере. Причина, по которой он показал мне эту ошибку, заключалась в том, что она была развернута в папке sub . В IIS я щелкнул правой кнопкой мыши на подпапке и извинился «Преобразовать в приложение», и после этого все заработало.

3
Martin Lietz

Если вы недавно установили или обновили пакет Microsoft.CodeDom.Providers.DotNetCompilerPlatform, дважды проверьте, что версии этого пакета, на которые есть ссылки в вашем проекте, указывают на правильную и ту же версию этого пакета:

  • В ProjectName.csproj убедитесь, что тег <Import> для Microsoft.CodeDom.Providers.DotNetCompilerPlatform присутствует и указывает на правильную версию.

  • В ProjectName.csproj убедитесь, что присутствует тег <Reference> для Microsoft.CodeDom.Providers.DotNetCompilerPlatform и указывает на правильную версию, как в атрибуте Include, так и в дочернем <HintPath>.

  • В web.config этого проекта убедитесь, что присутствует тег <system.codedom> и что его дочерние теги <compiler> имеют ту же версию в своем атрибуте type.

По какой-то причине в моем случае обновление этого пакета с 1.0.5 до 1.0.8 привело к тому, что тег <Reference> в .csproj имел свою Include, указывающую на старую версию 1.0. 5 . 0 (которую я удалил после обновление пакета), но все остальное указывало на новую и правильную версию 1.0. 8 . 0.

1
Ian Kemp

Вы должны обновить пакеты «Microsoft.CodeDom.Providers.DotNetCompilerPlatform» и «Microsoft.Net.Compilers» в своем проекте.

1
salah eddine

ASP.NET не ищет bin/debug или любую подпапку в bin для сборок, как это делают другие типы приложений. Вы можете указать среде выполнения искать в другом месте, используя следующую конфигурацию:

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

Тогда проблема вернулась. Я удалил Microsoft.CodeDom.Providers.DotNetCompilerPlatform и Пакет удаления Microsoft.Net.Compilers, но не помог. Тогда не установил никакой помощи. Очистили проект и построили без помощи. Перезапуск сервера не помог. Потом я заметил, что проекту нужен не самый последний, который в настоящее время является 1.0.5, а 1.0.3, так как в этом случае ошибка не могла загрузить версию 1.0.3. Поэтому я установил эту версию DLL, и теперь она работает.

1
tfa

Вот как я решил это: 

  1. Удалил папку bin в каталоге проекта.
  2. Нажмите на Build Solution. В VS2017 (Запуск от имени администратора)> Сборка> Построение решения .
1
BlackBeard

Я получал эту ошибку, потому что мой пользователь пула приложений был установлен на ApplicationPoolIdentity. Я изменил его на учетную запись пользователя/службы, которая имеет доступ к папке, и ошибка исчезла.

1
user3822295

Вот мои выводы. Я также столкнулся с этой проблемой сегодня утром. Я просто добавил моего текущего пользователя в пул приложений, в котором выполнялось приложение.

Шаги:

  1. Откройте IIS

  2. Нажмите на пул приложений

  3. Выберите пул приложений, в котором вы получаете проблему

  4. Правый клик -> дополнительные настройки

  5. Нажмите на трехточечный значок рядом с идентификатором

  6. Теперь выберите пользовательский аккаунт

  7. Дайте вашему компьютеру имя пользователя и пароль

  8. Сохранить

Обновите ваше приложение .. и оно начнет работать. Была некоторая проблема безопасности для доступа к dll.

1
Nekesh hedau

У меня было несколько проектов в решении, и веб-проект (проблема, приводящая к этой ошибке) не был установлен как проект запуска. Я установил этот веб-проект как проект автозагрузки и щелкнул пункт меню «Отладка» -> «Начать отладку», и он заработал. Я прекратил отладку, а затем попробовал снова, и теперь он снова работает. Weird.

1
tfa

В моем случае, я получил ошибку, когда у меня было веб-приложение в 4.5.2 и ссылочные библиотеки классов в 4.6.1. Когда я обновил веб-приложение до версии 4.5.2, ошибка исчезла.

0
user3554620

Убедитесь, что папка BIN полностью загружена или отсутствует в файлах.

0
TechDo

Убедитесь, что ваш проект полностью построен!

Нажмите на вкладку «Вывод» и убедитесь, что у вас нет ничего похожего на:

========== Перестроить все: 14 успешно выполнено, 1 не выполнено, 0 пропущено =========

Откройте папку bin и проверьте, не устарела ли она.

У меня была целая куча ошибок TypeScript, которые я сначала игнорировал, забывая, что они ломали сборку и приводили к тому, что не было скопированных DLL.

0
Simon_Weaver

У меня была та же самая проблема, и это было потому, что я переместил местоположение проекта и просто нуждался в воссоздании виртуального каталога.

0
Steven T. Cramer

Перейдите к Inetmgr из команды запуска В консоли диспетчера IIS Выберите папку приложения на веб-сайте по умолчанию Щелкните правой кнопкой мыши по этой папке, затем Преобразовать в ApplicationRun файл .asmx, включив Это решило проблему

0
Prabha Rajan

просто удалите пакет из консоли диспетчера пакетов из команды ниже

PM> Пакет деинсталляции Microsoft.CodeDom.Providers.DotNetCompilerPlatform

PM> Деинсталляция-пакет Microsoft.Net.Compilers

и затем установите его снова из диспетчера nuget  enter image description here

0
Hisham shahid

Исключение, с которым мы столкнулись, было не на локальном, а на удаленном сервере, CI Azure считывал его из папки пакетов, но упомянутые выше версии компилятора не были найдены.

Чтобы исправить это, мы изменили файл проекта так, чтобы он был похож на

Здесь нет ссылок ни на один из пакетов, прямо ссылающихся на переменные среды.

Это решило проблему, однако в наших случаях мы не используем пакеты напрямую из "package.config", вместо этого у нас есть отдельная папка для обеспечения целостности версий между командами.

0
Vikas Sharma