Развертывание C # ClickOnce для служб Windows?

Question

Каковы некоторые рекомендации по развертыванию службы Windows, которые необходимо обновить?

У меня есть служба Windows, которую я буду развертывать, но мне может потребоваться отладка и новые версии в процессе бета-тестирования.Каков наилучший способ справиться с этим?В идеале я хотел бы найти решение для развертывания в стиле ClickOnce для служб Windows, но, насколько я понимаю, его не существует.Что ближе всего я могу получить к ClickOnce для службы Windows?

Answer 1

Простое решение, которое я использую, - просто остановить службу и скопировать файлы из папки bin в папку службы.

Пакетный файл, чтобы остановить службу, а затем скопировать файлы, должно быть легко скомбинировано.

Net stop myService
xcopy \\myServerWithFiles\*.* c:\WhereverTheServiceFilesAre
net start myService

Answer 2

У меня есть система, которую мы используем на работе, которая, кажется, довольно хорошо работает с сервисами.Наша развернутая система имеет около 20-30 сервисов в любой момент времени.На работе мы используем продукт под названием TopShelf, вы можете найти его здесь http://topshelf -project.com /

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

D: \ Services \ ServiceName.exe Core.Profiles.Debug или
D: \ Services \ ServiceName.exe Core.Profiles.Production

для получения различных конфигураций ведения журнала.

Наш сценарий сборки создает сценарии install.cmd и uninstall.cmd для каждого из наших сервисов, и все, что мы делаем, - это копируем файлы на сервер и запускаем сценарий.Если мы хотим увидеть выходные данные отладки, мы останавливаем службу и дважды щелкаем по exe, и мы получаем консоль для чтения всех выходных данных.

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

Тем не менее, мое предложение, если вам нужна 100% доступность услуг, это иметь избыточную систему.Независимо от того, как вы настраиваете свою службу для обновлений, вы не сможете избежать аппаратного сбоя, вызывающего простои, без автоматической системы восстановления после отказа.Если бы указанная система была на месте, моя рекомендуемая стратегия обновления состояла бы в том, чтобы выключить 1 узел, обновить, проверить, включить, выключить другой узел, обновить, проверить и снова включить 2-й узел.Конечно, вы можете сделать это простым скриптом.Это может быть более сложная система, чем вам нужно, но если вы не можете перевести службу в автономный режим для простого перезапуска, который занимает 5 секунд, тогда вам действительно нужна какая-то система для решения проблем с оборудованием, потому что я могу гарантировать, что это произойдет в конце концов.

Answer 3

Я бы предложил использовать в этом подход «плагин», то есть Proxy Design Pattern.

При использовании этого шаблона независимый поток может проверять наличие обновлений в папке. Вам нужно будет использовать ShadowCopy при развертывании сборки. Когда поток обновления службы обнаруживает новую версию службы, он должен выгрузить текущую производственную сборку и загрузить новую версию, не останавливая саму службу. Даже больше! Ваша служба никогда не должна замечать разницы, если в вашей сборке нет взломанного кода.

Answer 4

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

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

Одной из идей, которая может сработать, является развертывание активного каталога (или некоторый аналогичный эквивалент). Если ваша служба развернута с помощью стандартного установщика типа MSI, AD позволяет автоматически обновлять приложение в рамках политики компьютера. Я подозреваю, что вам придется заставить сервер обновлять политику AD (путем перезагрузки или использования gpupdate из консоли), но в остальном это должно быть автоматическое развертывание.

Answer 5

Я бы предложил создать обычный проект установки и добавить выходные данные проекта службы Windows в этот проект установки.

Для получения дополнительной информации, пожалуйста, обратитесь к http://support.microsoft.com/kb/816169.