Это проект WebApi с использованием VS2015.
Шаг для воспроизведения:
Все работает отлично до тех пор, пока я не изменил путь сборки сборки с "bin \" на "bin\Debug \" Фактически, любой выходной путь, отличный от "bin \" , не будет работать.
Еще одна дополнительная вещь: наличие другого выходного пути в любом месте будет работать до тех пор, пока я оставил сборку в "bin".
Пожалуйста, помогите решить проблему. Я предполагаю, что это будет стоить проблемы при фактическом развертывании.
Если ваш проект имеет ссылки 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=\"Web\" /optionInfer+" />
</compilers>
Будьте осторожны, следуя этому совету ответа. Хотя это решает проблему под рукой, это почти наверняка вызовет другие проблемы на более позднем этапе.
У меня та же проблема. По-видимому, компилятор .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 достаточно долго, чтобы она стала лучшей альтернативой. для тебя.
Просто добавьте следующий пакет nuget в ваш проект - Microsoft.CodeDom.Providers.DotNetCompilerPlatform
.
Имела ту же проблему.
У меня такая же проблема, что мое приложение работало в Vs2013, но получило ошибку после обновления до Vs2015.
Я знаю, что это старый поток, но я бы хотел указать на возможную версию 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=\"Web\" /optionInfer+" />
</compilers>
</system.codedom>
</pre>
После обновления двух строк ошибка исчезла.
В соответствии с вашими этапами воспроизведения я предположил, что изменение пути вывода в свойстве приложения было вашим единственным изменением после создания приложения. Единственное, что делает это изменение, - это то, что он сообщает 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 в месте развертывания независимо от моего пути выходного пути. Я предполагаю, что ваше приложение должно по-прежнему работать над фактическим развертыванием.
Простой способ - Project> Управление пакетами NuGet...> Обзор (вкладка)> в поиске введите следующее: Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Вы можете установить или обновить или удалить и установить этот компилятор
Другое возможное решение может быть:
Перезапустите экземпляр Visual Studio с правами администратора !
В моем случае это произошло, когда я изменил разрешение папки приложения, и учетная запись IIS_IUSRS была удалена. После того, как я снова добавил IIS_IUSRS (IIS Manager- > YourWebApp → Изменить разрешение → Добавить IIS_IUSRS) в папку приложения и его работу.
Он остановился после публикации на рабочем сервере. Причина, по которой она показала мне эту ошибку, состояла в том, что она была развернута в папку sub. В IIS я щелкнул правой кнопкой мыши в подпапке и вымогал "Преобразовать в приложение", после чего он работал.
Вот как я это решил:
bin
каталоге проекта.Build Solution
. В VS2017 (Запуск от имени администратора)> Построить> Построить решение.Вот мои выводы. Сегодня утром я столкнулся с этой проблемой. Я просто добавил своего текущего пользователя в пул приложений, на котором было запущено приложение.
Шаги:
Откройте IIS
Нажмите на пул приложений
Выберите пул приложений, по которым вы получаете проблемы.
Щелкните правой кнопкой мыши → расширенные настройки
Нажмите значок с тремя точками рядом с идентификатором
Теперь выберите пользовательскую учетную запись
Укажите имя пользователя и пароль для вашего ПК
Сохранить
Обновите свое приложение.. и он начнет работать. Для доступа к DLL возникла некоторая проблема безопасности.
Я получал эту ошибку, потому что мой пользователь пула приложений был установлен в ApplicationPoolIdentity. Я изменил его на учетную запись пользователя/службы, которая имеет доступ к папке, и ошибка исчезла.
Тогда проблема вернулась. Я удалил как Microsoft.CodeDom.Providers.DotNetCompilerPlatform, так и Удалить пакет Microsoft.Net.Compilers, но без помощи. Затем не было никакой помощи. Убрал проект и не помог. Перезагруженный сервер не помог. Затем я заметил, что проект не нужен не последнему, который в настоящее время составляет 1.0.5, а 1.0.3, так как это ошибка не могла загрузить версию 1.0.3. Поэтому я установил эту версию dll, и теперь она работает.
Вы должны обновить пакеты "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" и "Microsoft.Net.Compilers" в вашем проекте.
У меня было несколько проектов в решении, и веб-проект (проблема с этой ошибкой) не был задан как проект StartUp. Я установил этот веб-проект как проект StartUp и нажал на пункт меню "Debug" → "Начать отладку", и он сработал. Я остановил отладку, а затем снова попробовал, а теперь вернулся. Weird.
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 успешно выполнено, 1 не выполнено, 0 пропущено =========
И откройте папку с bin
баком и проверьте, обновлена ли она.
У меня была целая куча ошибок машинописного текста, которые я сначала игнорировал, забывая, что они ломали сборку и приводили к тому, что не было скопированных DLL.
Исключение, с которым мы столкнулись, было не на локальном, а на удаленном сервере, CI Azure считывал его из папки пакетов, но упомянутые выше версии компилятора не были найдены.
Чтобы исправить это, мы изменили файл проекта, чтобы сделать его что-то вроде
Здесь нет ссылок ни на один из пакетов, прямо ссылающихся на переменные среды.
Это решило проблему, однако в наших случаях мы не используем пакеты напрямую из "package.config", вместо этого у нас есть отдельная папка для обеспечения целостности версий между командами.
Если вы недавно установили или обновили пакет 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.
просто удалите пакет из консоли диспетчера пакетов из команды ниже
PM> Удалить-пакет Microsoft.CodeDom.Providers.DotNetCompilerPlatform
PM> Удалить пакет Microsoft.Net.Compilers
и затем установите его снова из диспетчера Nuget
Просто выберите в меню "Создать" очистить имя проекта, чтобы исправить ошибку.
В моем случае я получил ошибку, когда у меня было мое веб-приложение в 4.5.2 и ссылочные классы в 4.6.1. Когда я обновил версию веб-приложения до версии 4.5.2, ошибка исчезла.
У меня была такая же проблема, и это было потому, что я переместил местоположение проекта и просто нуждался в воссоздании виртуального каталога.
Убедитесь, что службы IIS включены в функции Windows на вашем компьютере.