Альтернативы WiX Burn Bootstrapper? (Можно ли использовать загрузчик InstallShield LE?)
Исходная информация:
Раньше у нас был проект установщика на основе Visual Studio 2010, но наша ситуация с установкой стала намного сложнее, и в 2012 году, когда все проекты ушли, мы решили, что начнем изучать WiX / InstallShield LE.
Эта проблема:
InstallShield LE кажется слишком ограниченным в файлах MSI, которые он создает, чтобы соответствовать нашим потребностям - (например, если вы проверите предварительное условие Office 2007, даже если ошибка говорит, что вам нужен "Office 2007 или более поздняя версия", произойдет сбой, если у вас Office 2010 установленный вместо этого - вы можете проверить одно или другое, но вы не можете создать условие ИЛИ - есть гораздо больше, это только верхушка айсберга). - Бутстрэппер, который он создает, с другой стороны, просто супер!
WiX, с другой стороны, отлично работал для создания нашего MSI, но Burn Bootstrapper был просто одна головная боль за другой - мы наконец-то заработали - но теперь на коробках наших клиентов, он не только не может подняться, когда он запускает файл MSI, но Symantec SONAR обнаруживает его как вирус, и установка все равно блокируется! (Этого не происходит с InstallShield LE, и сертификаты для подписи кода слишком дороги для этого проекта.) Честно говоря, я бы хотел просто НЕ использовать Burn Bootstrapper.
Вопрос:
Какие есть альтернативы WiX Burn Bootstrapper? Можно ли использовать InstallShield LE один? А как насчет NSIS? (Интегрируется ли он с Visual Studio 2010/Visual Studio 2012?) - Я надеюсь выполнить наши предварительные требования для установки размера файла установщика через Интернет - и да, я должен также поддерживать.MSI. (в противном случае, я бы просто переключился на полноценный NSIS).
Разрешение:
Хотя я не мог заставить работать решение Кристофера Пейнтера, я пометил его как ответ, потому что считаю, что это лучший предложенный подход. Я пошел с довольно злым маленьким взломом решения, но если вы можете заставить подход Кристофера работать, я думаю, что это путь. Если ты не сможешь, возможно, мой хак тебя расклеит.
4 ответа
Приблизительно за $2K вы можете перейти на InstallShield Professional. Однако, если вы в основном довольны ISLE и можете жить только с одной функцией и без настроек пользовательского интерфейса, я могу решить проблему с условиями запуска для вас.
Смотрите мою статью в блоге:
Дополнение InstallShield с использованием установщика Windows XML - сертификаты
Идея заключается в том, что вы создаете модуль слияния WiX, который ищет две офисные версии и планирует настраиваемое действие "Ошибка" (MSI Type 19), которое использует два поиска в логическом или состоянии. Добавьте это в ваш проект ISLE, и вы просто "смешали" две технологии.
Professional также предоставляет вам редактор PRQ (XML prereq file). Затем повторное использование 30-дневного eval на виртуальной машине может дать вам тот же результат.
Вот сторона WXS этого:
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Module Id="ISWIX.REQUIRE.MSOFFICE20102013" Language="1033" Version="1.0.0.0">
<Package Id="10ed24f2-6c07-4066-9f39-ba9f66c2667b" Manufacturer="ISWIX, LLC" InstallerVersion="200" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="MergeRedirectFolder"/>
</Directory>
<Property Id="OFFICE2010FOUND">
<RegistrySearch Id="findOffice2010" Root="HKLM" Key="SOFTWARE\Microsoft\Office\14.0\Common\InstallRoot" Name="Path" Type="raw" />
</Property>
<Property Id="OFFICE2010X64FOUND">
<RegistrySearch Id="findOffice2010X64" Root="HKLM" Key="SOFTWARE\Microsoft\Office\14.0\Common\InstallRoot" Name="Path" Type="raw" Win64="yes" />
</Property>
<Property Id="OFFICE2013FOUND">
<RegistrySearch Id="findOffice2013" Root="HKLM" Key="SOFTWARE\Microsoft\Office\15.0\Common\ProductVersion" Name="LastProduct" Type="raw" />
</Property>
<CustomAction Id="ErrorNoOffice20102013" Error="[ProductName] setup requires Microsoft Office 2010 or 2013." />
<InstallUISequence>
<Custom Action="ErrorNoOffice20102013" After="AppSearch">Not OFFICE2010FOUND and Not OFFICE2010X64FOUND and Not OFFICE2013FOUND and Not Installed</Custom>
</InstallUISequence>
<InstallExecuteSequence>
<Custom Action="ErrorNoOffice20102013" After="AppSearch">Not OFFICE2010FOUND and Not OFFICE2010X64FOUND and Not OFFICE2013FOUND and Not Installed</Custom>
</InstallExecuteSequence>
</Module>
</Wix>
Я бы хотел, чтобы все проблемы, которые вы подняли, были исправлены. Если бы вы могли сообщать об ошибках по этим вопросам, это было бы очень полезно.
А пока, если вы используете WiX toolset v3.5+, вы можете посмотреть на setupbld.exe. Этот инструмент может создать крошечный установщик pre-req, который запускает pre-req, а затем один MSI.
Примечание: наша цель в наборе инструментов WiX состоит в том, чтобы в конечном итоге перечислить, что этот инструмент делает с Burn, поэтому сообщения об ошибках, где Burn не работает, очень ценятся.
NSIS может быть интегрирован с Visual Studio (2005/2008/2010 и 2012) с помощью дополнения под названием Visual & Installer. Inno Setup также поддерживается. Если вы ищете простое и дешевое решение, воспользуйтесь этим (как NSIS, так и Inno Setup - бесплатные системы с огромным сообществом).
У меня нет опыта работы с WiX, но NSIS и Inno Setup не могут создавать файлы MSI, только файлы EXE.
В конце концов Install Shield LE оказался для меня слишком большой головной болью, и я закончил тем, что создал проект установки на основе пустышки.vdproj старой школы 2010 года с правильными условиями (Windows Installer 3.1, .NET 4.0 и VSTO 2010).).
Я собрал его один раз и украл файл setup.exe (я убедился, что другие вещи, такие как код обновления и т. Д., Соответствуют моему текущему MSI-файлу на основе WiX - и созданный им MSI-файл - это то же имя, которое я хотел использовать, так далее).
Я упаковываю этот setup.exe вместе с моим MSI-файлом на основе WiX, и все отлично работает - это определенно огромный взлом - но это единственное решение, которое я смог найти, и то, и другое работает "из коробки" (-ish) и не работает отключить антивирус Symantec SONAR.
Я не собираю.vdproj каждый раз (я собрал его только один раз, я удалил MSI-файл и собрал файл setup.exe), поэтому в будущем Visual Studio 2010 не будет зависеть от этого пути.
Для менее хакерского подхода смотрите ответ @Christopher Painter - если вы можете заставить его подход работать на вас, я рекомендую его подход вместо моего.