Ошибка конфигурации в asp..net [дубликат]

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

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

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

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

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

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

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

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

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

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

PM> Uninstall-package Microsoft.Net.Compilers

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

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

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

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

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

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

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

Убедитесь, что службы Internet Information Services (IIS) включены в функциях Windows на вашем компьютере.

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

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

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

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

   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>
   

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. Открыть IIS
2. Нажмите на пул приложений
3. Выберите пул приложений, с которым вы сталкиваетесь
4. Щелкните правой кнопкой мыши -> расширенные настройки
5. Нажмите на значок с тремя точками рядом с идентификатором
6. Now выберите пользовательскую учетную запись
7. Укажите имя пользователя вашего ПК и пароль
8. Сохранить

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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