Каковы общие рекомендации по развертыванию и конфигурации приложений с .NET?

Question

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

У меня есть приложение .NET WPF, написанное для выполнения функциональных тестов производства. В настоящее время это программное обеспечение развертывается путем копирования исполняемого файла и его зависимостей с целевой системой. Аналогичным образом устанавливаются подчиненные системы связи, но installutil необходимо использовать для регистрации службы окон WCF. Все это делается вручную. Кроме того, файлы конфигурации считываются из пользовательских источников XML-данных, которые являются локальными для папки приложения. Нет приложения app.config.

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

Мои вопросы заключаются в следующем:

1. Что следует использовать для установки и развертывания? Мастер установки и развертывания? Однократное развертывание?
2. Как мне автоматизировать установку службы Windows? Лучший способ указать пользовательское имя пользователя/пароль для службы поддержки?
3. Что нужно делать с настройкой, если измененное хранилище папок приложений считается вредным, как мне это сделать? Изолированное хранилище приложений?

Ссылка на статьи для любого из вышеперечисленного была бы идеальной.

Answer 1

(1) Что следует использовать для установки и развертывания? Мастер установки и развертывания? Однократное развертывание?

Если вы действительно хотите свести к минимуму риск любых StuFF развертывания взлетов из-за человеческой ошибки, я буду использовать WIX (http://wix.sourceforge.net/), чтобы создать отдельные инсталляторы Msi как для клиентского приложения ВПП и обслуживание окон. WIX может быть довольно болезненным время от времени, но в значительной степени что-либо в плане развертывания может быть достигнуто. Существует специальный проект визуальной студии WIX, доступный после установки WIX на вашем ПК.

Ребята, с которыми я работал в прошлом, успешно использовали SMS или Active Directory, чтобы установить какие-либо из msi, которые я создал для них в прошлом, используя WIX, а не click-once. Это действительно не имеет никакого отношения к WIX.

(2) Как мне решить автоматизировать установку службы Windows? Лучший способ указать пользовательское имя пользователя/пароль для службы поддержки?

Есть много статей в Интернете, объясняющие, как установить службу Windows с помощью WIX, таких, как этот - Installing and starting a Windows Service using WiX. С помощью WIX вы можете установить пользовательские параметры имени пользователя/пароля, которые будут предоставлены во время установки. Эти параметры могут быть установлены через файл MST или через командную строку с использованием команды msiexec.exe.

(3) Что нужно делать с настройкой, если измененное хранилище папок приложений считается вредным, как я должен это делать? Изолированное хранилище приложений?

Использование WIX, изменяемые файлы конфигурации могут стать делом прошлого, как файлы настроек XML конфигурации для различных сред, включая производство может жить в отдельных файлах MST контролируемых только системными администраторами. Добавленная безопасность для паролей и т. Д., Которые живут в защищенных хранилищах с ключом, могут быть добавлены через командную строку, как описано в предыдущем ответе.

Параметры параметров передаются при установке до времени к сгенерированным различным конфигурационным файлам, которые затем могут быть установлены только для чтения или даже зашифрованы - Using WiX to fix up XML files when deploying to different environments.

Answer 2

Да, 1, проект установки и развертывания, легкий peasy. Как настроить проект установки для установки службы с помощью специального действия, подробно описано в обходном руководстве "Creating a service application".

Answer 3

Я не могу ответить на все ваши вопросы, но, по крайней мере, помогу с частью проблемы, с которой у меня есть опыт.

Я нашел на форуме сообщение, как в принципе интегрировать InstallUtil в вашу программу, в основном делайте то, что он делает для вас, чтобы установить службу, поскольку она встроена в .net. Итак, что сделал оригинальный плакат форума, и я воспроизвел себя в одной из моих базовых библиотек, в основном, если я хочу создать службу, я просто создаю консольное приложение, которое расширяет ServiceBase, переопределяет OnStart/OnStop и имеет все мои служебный код. Это здорово, потому что он позволяет мне отлаживать прямо из Visual Studio, а затем устанавливать его как услугу, просто означает запуск consoleapp.exe --install, и он выполнит все, что нужно сделать для установки службы.

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

I believe this is the link to the original forum post for writing you're own installer

Since you mentioned WCF, though I would include this link about doing WCF from a Windows Service

Answer 4

Мое предложение было бы использовать проект установщика Windows для Сервиса, так как очень просто настроить имя пользователя и пароль по умолчанию. Также легко установить состояние службы по умолчанию (автозапуск, ручной запуск, отключено, ...).

Для приложения WPF я фактически использую ClickOnce поверх Windows. Его легко настроить, и он автоматически обрабатывает обновления.

Было бы здорово использовать ClickOnce для части обслуживания Windows, но я не имел успеха в этом.