MSP против упаковки MSI. Что использовать для патчей?
В настоящее время я работаю над проектом, который развертывается с использованием пакета MSI. Чтобы исправить программу, мы просто развернем другой установочный пакет MSI, отличный от MSP. Это эффективный / действенный способ добиться этого, или мы должны вместо этого развертывать пакет исправлений MSP? У меня был опыт работы с MSI, но не с MSP. Как бы я также занялся созданием патча MSP? Я бродил по интернету и, похоже, ничего не нашел.
Заранее спасибо!
2 ответа
Выбор действительно за вами, хотя MSP предоставляет файлы меньшего размера, что может быть выгодно для больших проектов. В частности, в этой статье MSDN говорится:
Обслуживание приложений с помощью исправления установщика Windows, а не полного установочного пакета для обновленного продукта, может иметь преимущества. Патч может содержать весь файл или только те биты, которые необходимы для обновления части файла. Это может позволить пользователю загрузить обновление, которое намного меньше, чем установочный пакет для всего продукта. Обновление с использованием патча может сохранить пользовательскую настройку приложения через обновление.
Эта страница содержит советы по использованию MSIMSP утилита для генерации MSP-файла патча с учетом старого и нового MSI-пакетов.
Патчирование очень сложно и с ним трудно работать, и оно весьма ненадежно, если вы не следуете надлежащим методикам MSI.
Я использую его только тогда, когда мне нужно, чтобы добиться исправления, которое невозможно доставить другим способом. Примером этого является случай, когда последовательность деинсталляции продукта нарушена, поэтому деинсталляция не завершается, а переходит в режим отката. Затем я исправляю небольшое обновление, чтобы исправить ошибку в установленном продукте, а затем удаляю его. Большинство патчей, которые я сделал таким образом, были сделаны с помощью Wise Package Studio - и они работали хорошо.
Я также использую исправления для доставкиочень небольших исправлений в выпущенные продукты. Обычно это один или два файла с некоторыми срочными исправлениями. Любой сложный выпуск программного обеспечения может срочно нуждаться в таком патче через несколько недель после основного выпуска, так как неотложные проблемы обнаруживаются в дикой природе и требуется быстрое исправление. Это сделано для предотвращения больших загрузок для конечных пользователей. И в этих случаях я всегда включаю"включать целые файлы", чтобы предотвратить исправление на уровне битов, которое, как известно, подвержено ошибкам.
Многие люди хотят использовать исправления для доставки небольших ежедневных обновлений для тестировщиков качества. Забудь об этом. Это не стоит риска, конечно же, не усилий и практически не экономит время, если ваши тестеры не находятся за границей. Если вам нужно установить исправления для тестировщиков QA, никогда не используйте исправления на уровне битов, так как это не удастся, если они запутались в папке установки - что, вероятно, подойдут хорошие тестировщики QA.
Если вам нужно сделать исправления для выпущенного продукта, обязательно используйте все доступные QA-тестеры, и пусть они запускаются через исправления на разных платформах, обновление с разных версий, разных языков и т. Д. Это очень сложно чтобы получить право. Также желательно не ставить слишком много предыдущих выпусков с патчем, так как это быстро усложняет задачу.
В целом: имейте в виду, что исправления предназначены для исправлений. Ссылку на статью, возможно, стоит прочитать, если вы исследуете использование исправлений для вашего продукта. Это немного грязно, но описывает несколько препятствий MSI.