Использование отдельной сборки MSI для файлов конфигурации для каждой среды

Question

Для одного клиента я должен предоставить сборку, которую они используют в QA и производстве. Контрольная сумма файла сборки должна совпадать - она ​​не может измениться вообще между QA и производством. Конфигурация для каждой среды различна, поэтому у меня есть сборка, которая содержит только код, а затем отдельная сборка для каждой среды, которая содержит только файлы конфигурации, специфичные для этой среды. Конфигурации файла конфигурации помещают файлы в одно и то же место независимо от среды, поэтому код всегда может загрузить файл c: \ myapp \ myconfig.xml, который будет содержать настройки для этой среды. Большинство статей, которые я читал об этом (например, Скотт Хансельман ), содержат разные сборки для каждой среды, но это не сработает, поскольку значения контрольной суммы будут разными. Должен ли я развернуть эти файлы конфигурации другим способом или у меня есть жизнеспособное решение? Одна проблема с моим текущим решением состоит в том, что требуется несколько конфигурационных файлов, которые почти идентичны, но не совсем. Поэтому одно изменение должно быть добавлено к нескольким файлам, чего я бы хотел избежать, но я не знаю, как это сделать, кроме как во время сборки или с помощью внешнего сценария, который копирует нужный файл.

Answer 1

Не уверен, что ваши настройки сложнее, но у нас есть похожая проблема, и мы добавили класс пользовательских действий, который обновляет файлы конфигурации в зависимости от среды (которую пользователь выбирает во время установки), затем вы добавляете этот проект пользовательских действий в ваш проект установки. Таким образом, вы используете одну программу установки независимо от того, в какую среду вы устанавливаете.

Дайте мне знать, если вы заинтересованы, и я могу опубликовать несколько примеров или дополнительную информацию о том, как мы это сделали.

Вот еще несколько деталей:

1. Добавьте новый диалог в ваш проект установки, чтобы запросить среду у пользователя (мы используем диалог с 4 переключателями с четырьмя имеющимися у нас средами: dev, qa, staging и production)
2. Сконфигурируйте значения 4-х переключателей и свойство, которое будет устанавливать это значение, то есть «среда» (для последнего будет использоваться классом CustomActions)
3. Добавление проекта dll в ваше решение с помощью одного класса (CustomActions)

4. в классе CustomAction вы читаете свойство, которое мы настроили на втором шаге, как:

       if(!this.Context.Parameters.ContainsKey("environment"))
       {
           string error = "'environment' argument is null. Please configure config file manually";
           //...handle your error, etc.
           return;
       }
   
       string env = this.Context.Parameters["environment"];
   

5. теперь ваша переменная env содержит значение, которое мы присвоили каждой радиокнопке на шаге. Затем вы можете использовать оператор switch, чтобы решить, какую среду выбрал пользователь. и обновите ваш файл конфигурации соответствующим образом:

Конфигурация конфигурации = ConfigurationManager.OpenExeConfiguration (this.servicePath); // например, чтобы изменить строки подключения, которые вы используете: config.ConnectionStrings.ConnectionStrings ["oracle"] = "Строка dev conn here";

6. Вернувшись в проект установки, добавьте выходные данные проекта CustomActions в свой редактор CustomActions (меню «Вид» -> «Редактор» -> «Пользовательские действия»)

7. Наконец, настройте свойство CustomActionData вашего проекта установки для передачи среды и других переменных в класс CustomAction (мой выглядит примерно так: / serviceFolder = "[TARGETDIR] \" /serviceExe="blahblah.exe "/ serviceName =" MyServiceName "/ environment =" [ENVIRONMENT] "

Надеюсь, что это имеет смысл и относится к вашему решению!

Answer 2

Предполагая, что:

1) XML-файлы конфигурации

2) Общее количество изменений между сборками невелико (даже если они скопированы во многие конфигурационные файлы)

Я бы попросил установщик обновить файлы конфигурации во время установки

Например, мы используем WiX v3 для нашего установщика и обновляем несколько файлов конфигурации со значениями во время установки, используя элемент XmlFile