Управление зависимостью ада с помощью WiX и C # - PullRequest
4 голосов
/ 05 апреля 2010

Мы находимся накануне запуска продукта, и в последнюю минуту меня засыпают сообщения о сбоях, которые, похоже, связаны с нашим установщиком, который является проектом WiX3 с отдельными выходами для сборок x86 и x64. Это постоянная проблема, которую я всегда думал, что исправили, только чтобы узнать, что они все еще скрываются.

Сам продукт представляет собой набор двоичных файлов, которые взаимодействуют друг с другом с помощью удаленного взаимодействия .Net, включая службу Windows и небольшой COM-компонент, который загружается как дополнение в другое приложение. Служба работает как SYSTEM, часть COM работает в контексте низкого уровня прав, тогда как другие части выполняются в обычном пользовательском контексте. Другие части включают стороннюю библиотеку библиотеки объектов COM и общую библиотеку с интерфейсами .net Remoting.

Я наблюдал странное поведение MSI, особенно при обновлении версий. Между анальной реализацией строгого имени MS (в частности, проверкой точной версии перед загрузкой данной сборки), задокументированная ошибка WiX / MSI, приводящая к удалению критических файлов при обновлении (по существу, если файл в MSI обновления имеет тот же номер версии, что и у существующей установки, этот файл удален) (редактирование: возникли проблемы при создании указанной документации ...) и необходимость работать с виртуализацией Wow64 (MSI x86 может записывать данные только в реестр / хранилища HD через Wow64, все же x64 MSI не могут работать на x86 компьютерах ...), я готов уничтожить все это и перенести его на другую систему установки.

То, что я ищу, о советах + хитростях, приемах или предложениях о том, как правильно делать вещи, чтобы я не боролся с извращенным чувством логики установщика Windows. Я устал от борьбы с WiX / MSI / Windows Installer. Все, что ему нужно сделать, - это разместить файлы и ключи реестра там, где я говорю, обновлять их, когда это необходимо, и ничего не удалять, пока пользователь не удалится. Вместо этого зависимости удаляются волей-неволей, вызывая целую кучу неуловимых исключений (не может обернуть блок try{} вокруг объявлений функций) и используя GPF для всего приложения.

Меня особенно интересуют «лучшие практики» и примеры, касающиеся общих и зависимых библиотек DLL, и любые советы по , если файл должен быть отправлен в GAC, что он на самом деле отправляется в GAC и остается там, пока не будет целесообразно удалить его.

Спасибо!

Tom

Ответы [ 3 ]

3 голосов
/ 06 апреля 2010

Начните с чтения Полное руководство по установке Windows .

Готово? Отлично. Теперь подумайте о том, чтобы отказаться от существующей установки, начиная с нуля и заполняя ошибку приложения для всего, что вам в данный момент нужно «обойти» при установке. Практически каждый бит «искривленной логики», с которым вы боролись, призван сделать вашу установку более надежной и ремонтопригодной.

Если вы не хотите надежность и отказоустойчивость установщика Windows или если вы пытаетесь каким-либо образом обойти его, используйте что-то другое. Установщик Windows делает гораздо больше, чем просто «помещает файлы и ключи реестра туда, куда я говорю».

Когда вы пишете пакет MSI, вы определяете, как должна выглядеть целевая система. Вот как это выглядит после установки, как оно должно автоматически восстанавливаться, если файл удален или файл данных ключа поврежден. Вы определяете, как должна откатываться система, если пользователь позже отменит ее во время обновления с 1.0 до 2.0. Установщик Windows 100% управляется данными . С точки зрения разработки это самая сложная концепция для понимания, вы не можете просто отредактировать файл конфигурации или записать еще несколько данных и ожидать, что они сохранятся. Как только вы разберетесь с этим, установщик Windows станет настоящим куском, и вы разрабатываете свои программы и функции для работы в рамках его ограничений, а не пытаетесь освободиться от них:)

Несколько других полезных ссылок ...

1 голос
/ 18 июня 2015

Предполагая, что вы используете как минимум Wix 3.0, вы можете использовать MakeSfxCA.exe для упаковки зависимостей в одну DLL. (Это была надстройка от DFT - Deployment Tools Foundation.) Начнем с того, что убедитесь, что проект копирует ваши зависимые библиотеки DLL. Создайте файл CustomAction.config. Протестируйте с помощью простого файла .bat, например:

REM MyMakeSfxCA.bat - Запустить под $ (TargetDir); абс. пути требуются "% WIX% \ SDK \ MakeSfxCA" ^ % cd% \ Managed_custom_action_pkg.dll ^ "% WIX% \ SDK \ x86 \ sfxca.dll" ^ % cd% \ Managed_custom_action.dll ^ % cd% \ Dependent1.dll ^ % cd% \ Dependent2.dll ^ % cd% \ Microsoft.Web.Administration.dll ^ % cd% \ Microsoft.Deployment.WindowsInstaller.dll ^ % cd% \ CustomAction.config

Как только это сработает, преобразуйте в событие после сборки: "$ (WIX) \ SDK \ MakeSfxCA" ^ $ (TargetDir) \ Managed_custom_action_pkg.dll ^ "$ (WIX) \ SDK \ x86 \ sfxca.dll" ^ $ (TargetDir) \ Managed_custom_action.dll ^ $ (TargetDir) \ Dependent1.dll ^ $ (TargetDir) \ Dependent2.dll ^ $ (TargetDir) \ Microsoft.Web.Administration.dll ^ $ (TargetDir) \ Microsoft.Deployment.WindowsInstaller.dll ^ $ (TargetDir) \ CustomAction.config

В вашем файле .wxs ваш двоичный ключ будет выглядеть следующим образом: <Двоичный идентификатор = "Managed_custom_action_CA_dll" SourceFile = "$ (var.Managed_custom_action.TargetDir) $ (var.Managed_custom_action.TargetName) _pkg.dll" & # x2F; >

Для них CustomAction.config вы можете найти примеры в Интернете, такие как

Это лучший способ, который я нашел при работе с управляемым кодом.

0 голосов
/ 06 апреля 2010

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

Возьмите «ошибка удаления файлов» и «ошибку». Я не видел это некоторое время, но, если я вспоминаю, это обычно вызывается следующим сценарием:

сборка A: файл 1: 1.0.0.0

сборка B: файл 1: 1.0.0.0

Теперь вы идете сделать серьезное обновление, где у вас запланировано RemoveExistingProducts после CostFinalize. FindRelated Products обнаруживает, что ProductCode должен быть удален, Costing говорит, о, я вижу, что у меня 1.0.0.0, но 1.0.0.0 уже установлен, поэтому мне нечего здесь делать, а затем приходит RemoveExistingProducts и удаляет старую версию, тем самым удаляя файл 1.

Я всегда работал над этим, планируя RemoveEXistingProducts ранее, чем это было предложено Microsoft. У меня это работает годами.

Что касается ада зависимостей, я управляю линейкой программных продуктов, которая состоит из сотен функций, выраженных сотнями модулей слияния, и тысячами файлов (более 15 000), используемых десятками установщиков для десятков различных функций, интеграции, основного обслуживания и обслуживания. и ветки обслуживания_integ.

Как мне это сделать? Один фрагмент за раз и много автоматизации, SCM и виртуальных машин, чтобы убедиться, что все действительно работает так, как задумано.

Находясь так близко к доставке вашего продукта, единственный «ответ», который я могу вам предложить, - дать вам знать, что такие люди, как я, всегда доступны для найма. Вы будете удивлены, насколько быстро некоторые из нас смогут перевернуть проекты и получить программное обеспечение.

...