Я изучаю различные варианты развертывания пакета .NET-приложений. Развертывание - это больше, чем просто копирование файлов, нам нужно остановить / запустить службы, вызвать EXE-файл, который выполняет сценарии базы данных, инициировать несколько установок setup.exe и т. д.
Эти сценарии будут переданы третьей стороне, которая будет применять различные обновления приложений к серверам наших клиентов.
Двумя лучшими вариантами являются CS-скрипт и PowerShell, но я оставлю решение голосования.
ОБНОВЛЕНИЕ: на основании полученных ответов я чувствую, что должен уточнить. Во-первых, люди, применяющие обновления, будут типами системных администраторов; не конечные пользователи. Так что в этом случае полноценный установщик WiX, Мудрый и т. д., Вероятно, окажется излишним.
Во-вторых, можно с уверенностью предположить, что на этих машинах будут установлены .NET 2.0 и даже PowerShell (или CS-Script, или что-то еще). Мы создаем образы, чтобы указать, что будет установлено. Проблема в том, что после того, как мы выберем образ, помимо обновлений приложений, которые мы будем писать сценарии, будет очень сложно установить «новые» приложения.





На самом деле все зависит от того, что вам удобно и как конечный пользователь, если таковой будет, будет его использовать. Все языки сценариев позволят вам делать то, что вы хотите. Для этого вы даже можете использовать простой пакетный скрипт.
Если будут участвовать конечные пользователи, и они не должны быть системными администраторами, я бы посоветовал использовать полный установщик. Таким образом, им наглядно показывают, что делается. Если это для системных администраторов или просто для личного использования, любой язык сценариев позволяет вам сделать это первым, даже если это VBS.
Обратной стороной использования PowerShell в качестве среды сценариев для развертывания является то, что вы должны убедиться, что на целевых компьютерах установлены .NET Framework 2.0 и PowerShell. Для этого вам понадобится сценарий, и, следовательно, вы вернетесь к исходному вопросу без PowerShell.
Я люблю PowerShell как среду написания сценариев. Он прост в использовании, гибок и может легко обрабатывать сценарии развертывания. Кроме того, поскольку он работает на .NET, а вы развертываете .NET, у внутренних людей меньше накладных расходов на просмотр и отладку сценария.
Лично мне хотелось бы иметь сценарий начальной загрузки, который обеспечивает установку PowerShell, а затем использовать PowerShell в качестве фактического сценария развертывания.
Похоже, вы хотите создать пакет-оболочку для установки и настройки ряда других вещей ...
Как бывший разработчик установщика Windows, я настоятельно рекомендую NSIS для простого в создании и полностью управляемого сценариями процесса установки. Для NSIS доступно множество плагинов, которые позволят вам запускать внешние программы, запускать и останавливать службы, записывать вывод командной строки и в основном делать все, что вы можете себе представить, на их языке сценариев.
Ссылка для NSIS: http://nsis.sourceforge.net/Main_Page
Рекомендую WiX для создания инсталляторов. В нем есть все возможности, необходимые для выполнения хорошей работы, и он бесплатный, поддерживается Microsoft, декларативен и расширяем. Он прекрасно интегрируется в VisualStudio и MSBuild-Process.
Мы использовали разные подходы. В конце концов, то, что нам удалось, это:
Спекулятивно: рассмотрите возможность использования MS Deploy (на RC1). Он делает большую часть того, что вам нужно. Сейчас оцениваю.
Что плохо работает: Сборка из вышеперечисленных + батники. Со временем все будет стремиться перейти в исполняемые файлы и библиотеки установки, поскольку это технология, которая может справиться со всеми задачами и масштабироваться. Обязательные действия в пользовательском интерфейсе являются злом и требуют ручной установки.
У CS-Script и Powershell есть свои недостатки. CS-Script - неуклюжие схемы привязки сборок. Powershell: мало кто может на это взглянуть. Перед тем, как использовать их, проверьте правильность концепции каждого из них - может быть, они вам понравятся больше, чем мне. Мой опыт несложен для этого - после проверки концепции я переключился на IronPython.
Сравнивая CS-Script и PowerShell, вот некоторые преимущества CS-Script перед PowerShell: