Подтвердить что ты не робот

Microsoft.Web.Administration.ServerManager ищет в неправильном каталоге для IISExpress applicationHost.config

У меня есть странная проблема при попытке получить пулы приложений на текущей машине. Похоже, что когда установлен IISExpress, код Microsoft хочет проверить IISExpress в дополнение к полному IIS. IISExpress использует отдельные файлы applicationHost для каждого пользователя. Я не уверен, будет ли этот вызов требовать, чтобы он проверял все те, или только те, которые были у текущего пользователя. Несмотря на это, он не находит тот, который он ищет в каталоге "C:\Windows\system32\config\systemprofile \". Для пользователя должен быть% userprofile% или 'C:\Users\Administrator \', для которого пул приложений, выполняемый этим кодом, работает как.

Может кто-нибудь, возможно, знает, как этот каталог systemprofile может появиться?

Exception:-
System.IO.DirectoryNotFoundException: Filename: \\?\C:\Windows\system32\config\systemprofile\Documents\IISExpress\config\applicationHost.config
Error: Cannot read configuration file


   at Microsoft.Web.Administration.Interop.AppHostWritableAdminManager.GetAdminSection(String bstrSectionName, String bstrSectionPath)
   at Microsoft.Web.Administration.Configuration.GetSectionInternal(ConfigurationSection section, String sectionPath, String locationPath)
   at Microsoft.Web.Administration.ServerManager.get_ApplicationPoolsSection()
   at Microsoft.Web.Administration.ServerManager.get_ApplicationPools()
   at CustomCode.Classes.IIsApplicationPool.GetApplicationPool(String iisWebSitePath, String poolName)
4b9b3361

Ответ 1

Я настоятельно рекомендую прекратить использование локальной ссылки на Microsoft.Web.Administration, которая поставляется с IIS (даже если это в GAC). Это связано с тем, что он имеет очень специфический номер версии (т.е. 7.0.0.0), и эта версия может измениться в будущей версии Windows, и это повредит.

Вместо этого зайдите в пакет nuget: Microsoft.Web.Administration (https://www.nuget.org/packages/Microsoft.Web.Administration). Это в основном делает так, что вы можете иметь частное развертывание зависимостей IIS.

Ответ 2

Если приложение, в котором вы используете Microsoft.Web.Administration для проверки приложений, работает на IISExpress, оно всегда будет возвращаться к Microsoft.Web.Administration версии 7.9.0.0 из-за сборки в прямом доступе в aspnet.config в экспресс-службе IIS.

См. C:\Program Files (x86)\IIS Express\config\templates\PersonalWebServer\aspnet.config Вот проблема в конфиге:

<dependentAssembly>
  <assemblyIdentity name="Microsoft.Web.Administration"
                    publicKeyToken="31bf3856ad364e35"
                    culture="neutral" />
  <bindingRedirect oldVersion="7.0.0.0"
                   newVersion="7.9.0.0" />
  <codeBase version="7.9.0.0" 
            href="FILE://%FalconBin%/Microsoft.Web.Administration.dll" />
</dependentAssembly>

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

Альтернативно вы можете попробовать и удалить перенаправление сборки, но я этого не пробовал, и это может вызвать проблемы в других местах. Мы должны предположить, что команда IIS Express сделала переадресацию по какой-либо причине (кроме удобства): -)

Ответ 3

Я уже знаю, что ответ старый, но вы пытались указать другую версию DLL?

Картинка стоит тысячи слов:

enter image description here

Ответ 4

Как вы пытаетесь получить пулы приложений? Используете ли вы API-интерфейсы MWH (Microsoft.Web.Administration)?

  • Полный IIS поставляется с Microsoft.Web.Administration.dll(версия 7.0.0.0).
  • IIS Express поставляется с другой версией Microsoft.Web.Administration.dll(версия 7.9.0.0).

Кажется, что полная IIS пытается использовать специфическую сборку IIS Express. Я не уверен, как вы оказались в этом состоянии, но вы можете отключить IIS Express и посмотреть, не возникла ли эта проблема.

Edit:

Почему вы хотите использовать Microsoft.Web.Administration(MWA) версии 7.9.0.0 в своем веб-приложении? Он поставляется с IIS Express 7.5 для работы только с одним файлом applicationhost.config для каждого пользователя, и это не использует/не работает с inbox/полным файлом конфигурации IIS, который находится в \windows\system32\inetsrv\config\appliationhost.config.

В вашем случае веб-приложение, работающее под полным IIS, работает с идентификатором системы, поэтому MWA 7.9.0.0 пытается загрузить файл конфигурации из каталога "C:\Windows\system32\config\systemprofile".

Ответ 5

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

Ответ 6

Я только недавно столкнулся с этой проблемой. После прочтения довольно многих постов, это было самое близкое из того, что дало мне представление о том, что происходит. Хотя у меня не обязательно есть решение конфликта между двумя версиями (7.0.0.0 и 7.9.0.0) при работе в VS IDE, после нескольких часов борьбы с ним я нашел причудливый прием, который вы можете сделать обойти IDE авто-перенаправление.

В примере:

Разработка приложения, которое ссылается на Microsoft.Web.Administration.dll(7.0.0.0) из каталога inetsrv, и попытка выполнить любое из следующих действий, а также попытка правильно подключиться к доступу к определениям пула приложений реального IIS, а не IIS Express, с не установлены. При запуске скомпилированного кода вне среды IDE он всегда работает правильно, независимо от того, как он указан.

  • ServerManager sm = новый ServerManager();
  • sm.OpenRemote( "локальный");
  • sm.OpenRemote( "MYPC"); // Предполагая, что локальный компьютер называется MYPC

Все они запускают VS для перенаправления ссылки из 7.0.0.0 DLL на 7.9.0.0, что приводит к получению неверных сайтов или исключений COM.

Привычка, которую я обнаружил, состояла в том, чтобы всегда использовать OpenRemote(), даже при попытке открыть локальный IIS и указать "localhost" или "MYPC" в качестве "LocalHost" или "MyPc" (то есть любую комбинацию смешанного регистра, так что это не точное регистрозависимое соответствие "localhost" (все строчные буквы) или имени локальной машины.

Эта особенность может быть не характерной для всех версий VS. В настоящее время я использую VS Professional 2017 (15.9.11).

Как я уже говорил, он исправляет перенаправление, но определенно помогает при отладке.