Как избавиться от реликтов модульного тестирования в моем файле Web.config? - PullRequest
Новая
       8

Как избавиться от реликтов модульного тестирования в моем файле Web.config?

3 голосов
/ 15 июня 2011

При загрузке моего текущего проекта на наш промежуточный сервер я заметил, что файл Web.config моей инфраструктуры MVC Asp.net содержит некоторые ссылки на сборки под названием

  • Hostadapters.AspNetAdapter
  • QualityTools.Common
  • QualityTools.ExecutionCommon
  • QualityTools.Resource

Я сам не добавил записи, но, догадываясь по их именам, я подозреваю, что они былидобавлен мастером «Добавить юнит-тесты».

Проблема заключается в том, что при обращении к этим сборкам проект не запускается на моем промежуточном сервере, поскольку он не может найти соответствующие библиотеки DLL.Их пути жестко запрограммированы в Web.config: 

<httpModules>
  <add name="HostAdapter" type="Microsoft.VisualStudio.TestTools.HostAdapter.Web.HttpModule, Microsoft.VisualStudio.QualityTools.HostAdapters.ASPNETAdapter, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</httpModules>

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.VisualStudio.QualityTools.HostAdapters.ASPNETAdapter" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <codeBase version="10.0.0.0" href="file:///C:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio%2010.0/Common7/IDE/PrivateAssemblies/Microsoft.VisualStudio.QualityTools.HostAdapters.ASPNETAdapter.DLL" />
  </dependentAssembly>

Правильно ли я считаю, что эти сборки связаны с модульным тестированием?

Когда япопытался удалить некоторые из этих записей, сервер ответил с ошибкой 403 «Отказано в доступе: запрещено».Что может быть в этом смыслом, и как мне этого избежать?

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

Редактировать: Я прочитал предложение разбить конфигурацию на отдельные части.Это хорошее предложение, но оно не помогает мне решить мою непосредственную проблему: как, черт возьми, я могу получить любую конфигурацию, работающую на сервере?

Ответы [ 2 ]

3 голосов
/ 11 ноября 2011

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

Это объясняет, что они делают, и указывает на дополнительную информацию.

Для чего нужны файлы Web.Debug.config и Web.Release.Config?

Вот преобразования для удаления неисправных модулей: 

  <system.web>
    <httpModules>
      <add name="HostAdapter" xdt:Locator="Match(name)" xdt:Transform="Remove" />
    </httpModules>           
  </system.web>

  <system.webServer>
    <modules>
      <add name="HostAdapter" xdt:Locator="Match(name)" xdt:Transform="Remove"/>
    </modules>
  </system.webServer>
0 голосов
/ 15 июня 2011

Я бы хотел иметь отдельные файлы web.config для подготовки и работы независимо от других.

Часто существует множество параметров, которые необходимо изменить в целях разработки, например, длина кэша, параметры безопасности, URL-адреса и т. Д.

Исходя из моего опыта, использование одного и того же конфига - это путь к катастрофе: требуется 1 разработчик, чтобы изменить настройки, чтобы что-то работало локально, а затем проверить обновленный файл, и в итоге вы получите сломанный промежуточный сервер (или, возможно, живой)!

Если вы используете сборку, то просто заменить web.config на web.live.config или web.staging.config в процессе сборки.

Ваша проблема исчезнет.

...