Тип провайдера CodeDom "Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider" не может быть расположен

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

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

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

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

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

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

Ответ 1

Если ваш проект имеет ссылки 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

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

У меня та же проблема. По-видимому, компилятор .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 (даже если это странно называть компилятором сторонним), что создает проблемы с неработающими ссылками при настройке новых сред. Если вы решили установить dll в GAC, будьте осторожны и помните, что вы это сделали. Если вы этого не сделаете, загрузите nuget для каждого проекта еще раз и несите все досадные ошибки, вызванные им (по крайней мере, раньше случалось, когда мне это надоело, и я просто помещал файлы в GAC). Оба подхода могут вызвать у вас головную боль и создать проблемы, это просто вопрос о том, с какими проблемами вы предпочитаете иметь дело. Microsoft рекомендует использовать систему nuget, и, как правило, ее лучше слушать, чем неизвестного программиста в SO, если вы не устали от системы nuget и не привыкли иметь дело с GAC достаточно долго, чтобы она стала лучшей альтернативой. для тебя.

Ответ 3

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

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

Ответ 4

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

В Vs2015 щелкните правой кнопкой мыши папку "Справочник по проектам", чтобы открыть диспетчер пакетов NuGet.
В разделе "Обзор" найдите "DotNetCompilerPlatform" и установите "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" lib

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

Другое возможное решение:

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

Ответ 13

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>

Ответ 14

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

Ответ 15

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

Ответ 16

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

Ответ 17

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

Ответ 18

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

Шаги:

Откройте IIS
Нажмите на пул приложений
Выберите пул приложений, по которым вы получаете проблемы.
Щелкните правой кнопкой мыши → расширенные настройки
Нажмите значок с тремя точками рядом с идентификатором
Теперь выберите пользовательскую учетную запись
Укажите имя пользователя и пароль для вашего ПК
Сохранить

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

Ответ 19

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

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

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

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

Ответ 20

Если вы недавно установили или обновили пакет 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.

Ответ 21

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

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

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

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

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

Ответ 22

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

Ответ 23

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

Ответ 24

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

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

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

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

Ответ 25

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

Ответ 26

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

Ответ 27

Добавьте ссылку на сборку CppCodeProvider.

Ответ 28

По поводу этой ошибки я пробовал:

Очистка и перестройка проекта
Выгрузка и перезагрузка проекта
Изменение целевой структуры
Изменение пути вывода
Добавление самородков в GAC
Удаление пакетов uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform uninstall-package Microsoft.Net.Compilers и снова установите их.

Хотя все они кажутся правильными решениями, я смог генерировать только новые ошибки, и, в конце концов, ошибка может отображаться, когда отсутствуют определенные ссылки/нюансы.

В моем случае я недавно переустановил Microsoft Office и ссылался на сборки, такие как Microsoft.Office.Core. Новая установка, похоже, не включала необходимые пакеты, поэтому мое решение не могло быть правильно построено.

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

Похоже, неясное сообщение об ошибке из Visual Studio.

Ответ 29

В моем случае мой веб-проект не был загружен должным образом (он показывал проект, недоступный), затем я должен был перезагрузить свой веб-проект после открытия моей визуальной студии в режиме администратора, тогда все работало нормально.

Ответ 30

Если вы используете git, вы, вероятно, игнорируете .dll в коммите