Здравствуйте, vdimas, Вы писали:

V>И опять и снова — не о том аргументируешь.
О, очередной приступ некрофилии?
V>Это UI не надо рисовать ручками, поэтому его низкоуровневое представление абсолютно не принципиально.
Ну конечно же надо. Дефолтный UI устраивает чуть меньше, чем никого. А механизмов расширения — упс, нету.
S>>Во-первых, это новый стандарт, требующий разработки отдельного тула, который стоит денег.
V>Тул идёт в SDK.
Если уж захотелось откопать мёртвую тему, потрудитесь ознакомиться с предметом дискуссии. Речь идёт о принятии архитектурных решений — на момент проектирования WI никакого SDK и тула не было.
Зато был тул для рисования Dialog Templates. То есть неизвестный нам архитектор спустил в унитаз значительный объём корпоративных ресурсов — без малейшей к тому причины.
Просто потому, что ему так захотелось.
V>Любое расширение означает некий "левый" работающий код. Я уже указывал, что это будет дыра в безопасности.
От повторения чуши она не становится более умной. В любом инсталлере есть дофига "левого" работаюшего кода, и никого это не беспокоит. Чем код UI хуже, чем код custom actions?
А если мы уж допустили чужой код в одном месте, то какой смысл запрещать его в другом?
Тем более, что код гуя, в отличие от кода custom actions, работает под ограниченными привилегиями текущего пользователя, а не в контексте сервиса windows installer.
V>Забудь про рукописность UI.
C чего это вдруг? Глаза откройте — 99% инсталляторов используют рукописный UI. То есть мы имеем мега-дорогой, переусложнённый, неудобный инструмент, который ещё и не покрывает потребности целевой аудитории.
Это даёт нам просто канонический пример архитектурного факапа.
V>Бла-бла-бла.
V>MSI создавался для установки продуктов офиса.
О, у вас появилась новая идея, как оправдать идиотскую точку зрения "windows installer архитектурно оправдан".
Вообще-то — нет. WI позиционировался как штатный инструмент для установки чего угодно.
Да, многие сценарии в нём были навязаны офисной командой. Но office team не диктовала, как реализовать всё это внутри. Можно было принимать любые архитектурные решения, а не только идиотские.

V>Там полно сложных сценариев и они все покрыты. Если тебе надо указать конкретный инстанс SQL-сервака, то под это дело заводится "символ", т.е. переменная и указывается как параметр, либо, если не указана, то можно дернуть CustomAction для демонстрации юзверю любого диалога.
То есть это уже не дыра в безопасности?
V>Например, в нашей инсталляхе диалоги были вообще нейтивные, а не дотнетные. Диалогов было несколько и с нетривиальной логикой — вот как раз для указания настроек сервака приложения, с возможностью проверки этих настроек. А для сервака приложений в инсталляхе — указать адрес/инстанс SQL-сервака.
Дело не в указании адреса/инстанса, а в том, что ломается весь механизм проверки наличия предыдущих версий софта — потому что их может быть одновременно много.
V>Кароч, ВСЕ, ну т.е. вообще все приведённые тобой контр-примеры — это какой-то детский лепет, который у разработчика занимает не более рабочего дня.
Это просто вы, как обычно, выступаете на незнакомую вам тему.
V>Не видел бы, не давал советов. Я ведь увидел еще тогда, что все советы прошли мимо уха не задерживаясь. Такое ощущение, что или я плохо объясняю, или кого-то совершенно не интересует обсуждаемый предмет, а интересует исключительно подвергнуть MSI обструкции любыми способами. ))
Вы не понимаете сути. Речь не о том, что убогость MSI нельзя обойти — конечно можно! Ведь продукты-то ставятся! Я разработчик — я вообще любую разрешимую проблему могу решить.
Мы сейчас обсуждаем не применение WI на практике — тем более, что с этой темой вы очень поверхностно знакомы. Мы обсуждаем архитектуру этого продукта. И если бы разработчики WI думали головой, а не тем местом, которым они думали, то этих "легко разрешимых" проблем бы не было вообще. Конечно, если убогая технология не позволяет мне подменять один контрол — то я перерисую весь диалог. Ну, будет это в 10 раз дороже — так я ж не бесплатно это делаю, зарплату получаю.
Ок, диалог плохо сочетается с остальными шагами визарда — давайте весь визард заменим на кастомный код. Ещё впятеро дороже получилось — но чего уж там, деньги-то не мои.

Вы посмотрите на это со стороны производителя — выброшены мега-деньги; кто-то сидел, ночей не спал, придумывая структуру табличек с контролами. Кто-то писал тул. QA гоняло всю эту чушь туда-сюда. Документация писалась и переводилась на разные языки. А на практике — нихрена это никому не помогает: всё уехало в помойку. Все, даже признанные знатоки MSI типа vdimas, пишут нативные диалоги вместо реляционного убожества.

V>Спасибо.
V>Тут стоило включить воображение. Хакнуть на лету некий бинарный код custom action какого-нить полученнго из надёжного источника продукта — это сложно. А если добавить фичу описания ЛЮБЫХ проверок — то это будет некий язык программирования. Скриптовый, скорее всего. который еще и текст сможет исполнять, скорее всего. А ему подсунул что-то левое из окружения (например, перехват некоторых консольных команд) — и делай что хочешь из тех самых elevated privileges, под которыми бедный админ запустил инсталляху, полученную из надёжного источника.
ОМГ. Вы сегодня положительно в ударе. А что вам мешает включить воображение и представить себе бинарный код, который запускает wscript.exe с перехватом некоторых консольных команд? Ну, если уж задача стоит упороться в дым?
А если вы думаете, что бинарный код так делать "просто не будет, потому что ему незачем", то, простите, и скрипт вычисления custom condition тоже "просто не будет".

V>Это много говорит о твоей внимательности. Я же предлагал уже решение для твоих проблем с установкой сервиса (у нас была такая же задача) — создаешь проект-заглушку в дотнете с установкой сервиса и перегоняешь полученный пакет в WiX. И вот как раз один из типовых кусков таким образом и нарисовался.
Речь не о моих проблемах. Я все свои проблемы с инсталляторами решил ещё до 2010 года. Речь о причинах, по которым эти проблемы возникли. В нормально спроектированной системе таких проблем быть не должно вообще, от слова совсем.
V>И?
И напороли такой чуши, что я работать не мог от смеха.
V>Зачем msiexec.exe? АПИ инсталлера полон, ты можешь сам написать утилиту-аналог msiexec.exe за пару вечеров под основные сценарии. Причем, эту утилиту можно написать на каком-нить скриптовом VBS.

Вы дома посмотрите, какой процесс у вас кушает CPU в процессе исполнения вызовов этого API.

V>Пока что выяснилось, что ты за деревьями не увидел леса. Выбрав в кач-ве основного фокуса приложения усилий WiX, ты не потратил должного времени на изучение структуры таблиц инсталляхи, на изучение COM-АПИ инсталлера, на понимание правил многократного разыменования референсов.
V>Кароч, ты начал не оттуда. К стадии WiX надо было подходить только освоив все предыдущие стадии. Горе тому, кто пытается пользоваться инструментом под некую предметную область, не понимая самой предметной области. Обезъяна с гранатой, как грится.
Опять мимо. WiX — это было последнее, к чему мы пришли. Наевшись и стандартного тулчейна, и купленного InstallShield, и ручного разбора с Orca, и всего остального.

V>Во-во. Нубство как оно есть.

V>Компонентом может быть что угодно, например, запись в реестре или параметр, который достаётся через кастомную акцию.
Садитесь, два.
V>Кароч, курить, что есть "компонент".
"Что угодно", my ass. Ну, покажите мне, как описать компонент, который имеет версию, определяемую через custom action, и никак не отражён в файловой системе. Что будем писать в KeyPath?

V>Версии надо присваивать продуктам, а не компонентам. Ну и все танцы вокруг т.н. "кода обновления" или уникального нового кода, чтобы разные версии жили одновременно, не мешая друг другу.
Это кто вам такое сказал?
S>>Вы почитайте немножко вот здесь: http://msdn.microsoft.com/en-us/library/aa368070(v=vs.85).aspx
V>Это не ответ. Тем более это не ответ от тебя, т.к. если ты ручками MSI АПИ не дергал, то не тебе отсылать к доке по нему. ))
Это не MSI API. Там про API ничего нету. Там рассказано, как писать custom action.

V>Я же описал, как получить "скелет" для грамотно описанной custom actions. Понятное дело, что породить подобный скелет с 0-ля ручками — это застрелиться. А зачем ты так делаешь?
Нет, ничего про скелет custom action написано не было. Кроме упоминания про многократное разыменование — это, надо полагать, единственное, что вы делали реально в инсталлере.

V>Я как раз предлагал сваять скелет на MSI и перегнать его в WiX, вычленив необходимое.
Вы путаете custom action со структурой пакета. "А строил из себя спеца." (TM)
Чтобы вы примерно поняли, о чём речь: допустим, один из компонентов вашего продукта — это служебный SSL сертификат, который ставится на backend-сайт. Ваша задача — описать custom action, который его поставит, если его не было, заменит, если он был, но старый, и не будет трогать, если он уже заменён на более новый. Под "ставится" мы подразумеваем регистрацию в IIS и активацию для соединений по порту 8443. При деинсталляции фичи, в которую входит этот компонент, нужно его снести. Какие шаги вы предпримете для написания custom action? Где вы возьмёте "скелет"?

Ещё раз: мы обсуждаем не мою личность, как разработчика инсталляторов. Мы обсуждаем клиническую убогость архитектуры Windows Installer, которая создаёт в разы больше проблем, чем решает.
То, что другие разработчики смогли потратить человекогоды для того, чтобы заполнить некоторые дыры этой архитектуры, хорошо для нас, как прикладников. Но плохо для тех, кто всё это придумывал с самого начала.