MSI vs nuget: какие из них лучше для непрерывной доставки? - программирование

MSI vs nuget: какие из них лучше для непрерывной доставки?

Обсудить следующую тему. Существует приложение, которое в настоящее время развертывается с хорошим знанием метода xcopy. Этот подход затрудняет управление зависимостями, обновлениями файлов и т.д. Существует идея начать развертывание приложений с помощью некоторых пакетов, вы знаете, как вы это делаете в Linux с помощью RPM, но для Windows.

Итак, у меня вопрос: какую систему пакетов лучше использовать для Windows Classic Windows Installer (msi) или nuget или что-то еще?

4b9b3361

ОТВЕТЫ

Ответ 1

  Ad-Hoc: Как избежать типичных ошибок проектирования в моем решении по развертыванию WiX/MSI? - очень грязное и не идеальное специальное резюме общих проблем, обнаруженных в файлах MSI. Не хорошо. Лучше чем ничего? Материал, которого нет в книгах (слишком грязный).

Важная тема: Как избежать случайного распространения конфиденциальной информации в моем MSI?

WiX & MSI:

MSI - это принятый стандарт корпоративных приложений. Он имеет некоторые основные корпоративные преимущества (and the short, concise version) по сравнению с традиционным развертыванием методы. WiX - это новый способ создания файлов MSI с открытым исходным кодом.

Другие инструменты:

Hello World & Здравствуйте, WiX:

Пример кода:

Быстрый запуск WiX. Вот некоторые из лучших примеров кодовых ссылок, которые я нашел:

And finally:

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

И проверьте наличие каких-либо явно отсутствующих сред выполнения. Например: .Net, .Net Core, Java, Silverlight, Direct X, VC++ Runtime, MS-XML (наследие), etc....

Custom Action Debugging:

MSI logging:

Event Viewer:

  • Удерживая нажатой кнопку Windows Key, коснитесь R, введите eventvwr.msc и нажмите Enter.
  • Перейти к Windows Logs => Applications. Ищите MsiInstaller events.
  • Проверьте и другие журналы (Security, System, Configuration).

General Debugging:

Debugging Tools:

Код ошибки. Поиск кодов ошибок и сообщений об исключениях.

A Deployment Mnemonic: A general mnemonic to think about deployment problems: What is locking (in use), what is blocking (permissions), what is corrupt (disk, malware, configs, encryption) what are unexpected system states (disk space, time & date settings, language, licensing, windows patch state, path too long, PendingFileRenames, etc...), what are incompatible products (things that can't co-exist), what is unreachable or misconfigured (what points to erroneous locations и resources: network server names, disk paths, URLs, databases, services, UAT environments, PROD environments, etc...) и last but not least: what is missing (runtime, resource image, settings file, etc...)?

Обновление:

Некоторые другие ссылки WiX:

Несколько хороших начальных ссылок для изучения Wix:

Извлеките файлы из Setup.exe WiX Bundle или из самого файла MSI:

Как я уже писал в моем предложении "Быстрый старт Wix" выше: Wix практический. Просто сосредоточьтесь на простых, но полных реальных примерах, таких как пример из Codeproject - чтение одной документации, вероятно, будет просто запутанным.

Сосредоточьтесь на том, чтобы разбить ваше приложение на компоненты и настроить серьезное обновление. Как правило, используйте один файл для каждого компонента и прочитайте этот ответ, чтобы лучше понять, как создать компонент: Изменить GUID компонента в wix?

Основное обновление - это наиболее часто используемый механизм обновления для развернутого программного обеспечения (другой распространенный тип обновления - незначительное обновление). Очевидно, очень важно, чтобы вы могли обновить то, что уже развернули. Подготовьте сценарии обновления до развертывания первой версии программного обеспечения, чтобы вы были уверены в своем решении для развертывания.

После того, как вы настроили свои компоненты и ваше решение по обновлению работает, остальные части встают на свои места, когда вы выполняете свои требования по развертыванию приложений и проверяете образцы на учебном сайте Wix: https://www.firegiant.com/wix/tutorial/.

Для тех, кто пишет код Wix напрямую (без редактора графического интерфейса), я предлагаю вам проверить этот ответ, чтобы кратко сохранить исходные файлы: Синтаксис для направляющих в WIX?

Далее читайте:

Ответ 2

Теперь я иду по этому пути, где унаследовал программное обеспечение, использующее MSI/WiX для установщика, но смотря на преобразование нашего процесса в непрерывную доставку и выталкивание обновлений, которые установлены без взаимодействия с клиентом. Я считаю, что его некорректно использовать дырочку nuget в качестве инструмента SDK, по сути, это инструмент для развертывания версий файлов. Кроме того, если программное обеспечение, которое вы развертываете, уже много отвечает на nuget, и вы уже упаковываете свои сборки в пакеты nuget для внутреннего использования, то зачем добавлять дополнительные компоненты в состав для этого? упакуйте файл nuget.exe в свой msi, периодически обновляйте его, сделайте.

Я знаю, что WiX поддерживает создание патчей, но похоже, что это запоздалая мысль. Кроме того, что произойдет, если ваш патч не сможет выполнить установку? Установка исправлений не работает? У вашего основного установщика требуются разрешения UAC, в то время как ваш патч не работает?

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

MSI больше похожа на pull - u получите пакет, а затем установите его. Nuget больше похож на push stratergy - вы получаете имя пакета, устанавливаете его, а затем периодически можете вызывать обновление и загружать и устанавливать новую версию.