Не удалось найти тип поставщика CodeDom «Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider».

101

Это проект WebApi с использованием VS2015.

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

  • Создать пустой проект WebApi
  • Изменить выходный путь сборки с "bin \" на "bin\Debug \"
  • Run

Изображение 449

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

Еще одна дополнительная вещь: наличие другого выходного пути в любом месте будет работать до тех пор, пока я оставил сборку в "bin".

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

  • 0
    Могу я спросить, почему вы изменили путь вывода вашего веб-приложения? Спасибо.
  • 0
    Это исключение происходит со мной каждый раз, когда я обновляю ранее запущенное приложение ASP.NET MVC во время компиляции msbuild .
Теги:
msbuild
asp.net-web-api

25 ответов

86

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

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

Выполните следующие действия:

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

    PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
    PM> Uninstall-package Microsoft.Net.Compilers
    
  • Удалите следующий код из файла 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>
    

  • 2
    Я застрял на "ошибка сервера в" / "приложении" в течение дня. Я компилирую простое приложение Hello World в Visual Studio 2015, развертываю его на веб-сервере и получаю эту ошибку. Удаление вышеприведенных строк <compiler> также решило эту проблему. Я хотел бы знать, как на земле это происходит и есть ли лучшее решение. Я нахожу совершенно невероятным, что вы не можете развернуть приложение hello world таким образом, не сталкиваясь с проблемами, это как MS не выполняет никакого тестирования: -)
  • 3
    Чтобы включить Roslyn, вы можете увидеть следующую статью Включение платформы компилятора .NET («Roslyn») в приложениях ASP.NET. Почему компиляция Roslyn в ASP.NET? Включение новых компиляторов Roslyn в ваше приложение ASP.NET приведет к двум основным преимуществам: * Поддержка новых языковых функций * Потенциально улучшенное время запуска / предварительной компиляции приложения
Показать ещё 3 комментария
35

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

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

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

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

Теперь по какой-то причине милые джентльмены из 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 достаточно долго, чтобы она стала лучшей альтернативой. для тебя.

  • 32
    Это не должно быть в GAC. Весь смысл подхода Nuget заключается в том, чтобы ваш проект использовал конкретную версию C # или VB.NET без каких-либо изменений в хост-системе. Смотрите это сообщение от Дамиана Эдвардса из MSFT: blogs.msdn.microsoft.com/webdev/2014/05/12/…
  • 0
    Как бы то ни было, лично мне не нравится, когда меня заставляют искать новые подходы. Более того, мне постоянно приходится решать проблемы при развертывании проектов в новых средах при использовании нюгетеров из-за несоответствующей версии и случайных обновлений, которые делают люди. Для меня нюги чрезвычайно раздражают и отнимают много времени. Я понимаю плюсы и минусы Nuget, я согласен с тем, что общая идея довольно крутая, я все же предпочел бы однажды поместить необходимые файлы в gac и забыть о них. При развертывании релизной версии я бы все равно скопировал эту dll
Показать ещё 10 комментариев
23

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

Имела ту же проблему.

  • 0
    Просто будь немного осторожнее; он перезаписывает 'compilerOptions' в файле web.config, поэтому перед установкой обязательно сохраните все пользовательские значения.
16

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

  • В Vs2015 щелкните правой кнопкой мыши папку "Справочник по проектам", чтобы открыть диспетчер пакетов NuGet.
  • В разделе "Обзор" найдите "DotNetCompilerPlatform" и установите "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" lib
  • 2
    Спасибо за подсказку, повторно щелкнув правой кнопкой мыши папку «Проекты», чтобы открыть диспетчер пакетов.
  • 3
    Попробуйте сначала удалить его, а затем снова установить в NuGet. Это сработало для меня.
Показать ещё 1 комментарий
12

Я знаю, что это старый поток, но я бы хотел указать на возможную версию 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>

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

  • 1
    У меня есть проблемы с DotNetCompilerPlatform каждый раз , когда я обновить его.
  • 2
    Если вы удалите атрибут версии, он также будет работать и предотвратит повторное возникновение ошибки при следующем обновлении.
Показать ещё 1 комментарий
9

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

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

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

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

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

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

6

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

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

Изображение 6038

3

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

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

Изображение 6039

3

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

  • 0
    Я добавил разрешения IUSR, но это было недостаточно. Мне пришлось добавить "IIS_IUSRS", и тогда это сработало.
3

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

  • 0
    Конвертировать в приложение было все, что мне было нужно. (Это был новый проект, который раньше не публиковался.)
1

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

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

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

Шаги:

  • Откройте IIS

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

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

  • Щелкните правой кнопкой мыши → расширенные настройки

  • Нажмите значок с тремя точками рядом с идентификатором

  • Теперь выберите пользовательскую учетную запись

  • Укажите имя пользователя и пароль для вашего ПК

  • Сохранить

Обновите свое приложение.. и он начнет работать. Для доступа к DLL возникла некоторая проблема безопасности.

1

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

1

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

1

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

1

У меня было несколько проектов в решении, и веб-проект (проблема с этой ошибкой) не был задан как проект StartUp. Я установил этот веб-проект как проект StartUp и нажал на пункт меню "Debug" → "Начать отладку", и он сработал. Я остановил отладку, а затем снова попробовал, а теперь вернулся. Weird.

1

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

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

Нажмите на вкладку "Вывод" и убедитесь, что у вас нет что-то вроде:

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

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

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

0

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

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

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

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

0

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

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

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

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

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

0

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

PM> Удалить-пакет Microsoft.CodeDom.Providers.DotNetCompilerPlatform

PM> Удалить пакет Microsoft.Net.Compilers

и затем установите его снова из диспетчера Nuget Изображение 6040

0

Просто выберите в меню "Создать" очистить имя проекта, чтобы исправить ошибку.

0

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

  • 0
    Получилась действительно та же ошибка при установке Umbraco 8, для неправильной версии .Net (требуется 4.7.2) вместо 4.5.2 (по умолчанию VS 2017)
0

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

-1

Убедитесь, что службы IIS включены в функции Windows на вашем компьютере. Изображение 6041

  • 0
    Информационные службы Интернета были отключены на моем компьютере - я включил его, и исключение сохраняется.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню