2010-11-11 3 views
33

Я использовал конфигурационные преобразования в VS2010 в последнее время, но в замешательстве, почему некоторые преобразования применяются непосредственно к Web.config в пакете, а другие хранятся против токена в SetParameters.xml, а затем применяются в публикации.Почему некоторые Web.config преобразуют токены в SetParameters.xml, а другие нет?

Например, возьмите Web.config со следующей строкой подключения и настройкой приложения:

<connectionStrings> 
    <add name="AutoDeployDb" connectionString="Data Source=(local);Initial Catalog=AutoDeploy;User ID=AutoDeployUser;Password=Passw0rd"/> 
</connectionStrings> 
<appSettings> 
    <add key="ChartImageHandler" value="storage=file;timeout=20;dir=c:\TempImageFiles\;" /> 
</appSettings> 

Тогда вот соответствующие конфигурации преобразования для текущей конфигурации сборки:

<connectionStrings> 
    <add xdt:Transform="Replace" xdt:Locator="Match(name)" name="AutoDeployDb" connectionString="Data Source=MyDevServer;Initial Catalog=AutoDeploy;User ID=AutoDeployUser;Password=s*#@Kdsl" /> 
</connectionStrings> 
<appSettings> 
    <add xdt:Transform="Replace" xdt:Locator="Match(key)" key="ChartImageHandler" value="storage=file;timeout=20;dir=d:\inetpub\AutoDeploy\TempImageFiles\"/> 
</appSettings> 

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

Теперь зайдите в файл SetParameters.xml в результирующем пакете, и только строка соединения имеет узел setParameter. В папке Web.config папки PackagTmp преобразование параметра приложения уже применяется, когда строка подключения имеет значение $ (ReplacableToken_AutoDeployDb-Web.config Connection String_0), которое применяется только при развертывании пакета.

Почему это? Это что-то конкретное для строк подключения (или, наоборот, к настройкам приложения)? Я ценю rationale of this approach, я просто не понимаю, почему он применяется к некоторым настройкам, а не к другим.

Может ли кто-нибудь пролить свет на это?

ответ

37

Это фактически не имеет ничего общего с конфигурационными преобразованиями. Я только что разместил очень подробный блог по адресу http://sedodream.com/2010/11/11/ASPNETWebApplicationPublishPackageTokenizingParameters.aspx. Но какая-то информация здесь для вас.

В трубе веб-публикации (WPP) мы обрабатываем строки подключения как специальные артефакты. Мы будем автоматически создавать параметры для всех строк подключения. Это связано с тем, что во многих случаях при развертывании приложения вы хотите изменить строки подключения. Мы не создаем автоматически параметры для любого значения appSettting. Теперь вернемся к вашему вопросу, почему мы токенизируем строки подключения? Мы действительно делаем это, чтобы убедиться, что вы не пропустите настройку значения, а затем случайно попросите приложение обновить неправильную БД. Мы вам помогаем, создавая эти параметры для вас. Также вы можете отключить это поведение, если хотите. Вы можете установить свойство MSBuild AutoParameterizationWebConfigConnectionStrings на false.

+3

Это было бы невероятно полезно, если бы был простой способ (через свойство MSBuild) обрабатывать appSettings (либо конкретные, либо весь набор) таким же образом. например AutoParameterizationAppSettings = true. –

+5

Эта статья неплоха в определении способа решения моей проблемы: http://vishaljoshi.blogspot.com/2010/07/web-deploy-parameterization-in-action.html –

+1

Но зачем кому-то это хотеть? –

1

Что касается развертывания, существует одна существенная разница между ними. При импорте веб-пакетов в IIS:

  • Строки подключения автоматически включаются в диалоговое окно мастера для дальнейшей параметризации.
  • Настройки приложения по умолчанию не будут. Если вы действительно хотите сделать это, пожалуйста, следуйте инструкциям, приведенные в «Пользовательская Параметризации - настройки приложения в файл web.config» секциях Configuring Parameters for Web Package Deployment

Дифференциация создает границу ответственности между разработчиком и ОПСОМ. С одной стороны, вы устанавливаете параметры целевой среды (базы данных, кеша, ключа/секретности AWS и т. Д.) В строках соединений, о которых необходимо позаботиться. С другой стороны, вы помещаете нерелевантные параметры в разделе настроек приложений, так что можно избавиться от бремени Ops для определенных продуктов и бизнес-логики.

В моей компании один из оппонентов часто несет ответственность за несколько продуктов. Вы действительно не можете требовать от них знать столько знаний о продукте, сколько вы. Чем меньше им нужно обратить внимание, тем счастливее будет жизнь.

 Смежные вопросы

  • Нет связанных вопросов^_^