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

V>> Можно лишь поспорить относительно отдельных таблиц и связей. Я соглашусь только с иронией по поводу представления UI, но блин, в сотый раз оговорюсь, что эта ирония бессмыслена изначально, бо с выходом самой первой версии инсталлера в его SDK был тул по визуальному редактированию и тестированию UI.
S>Тул здесь совершенно ни при чём. Речь о том, что негодна сама идея реляционного описания UI.

И опять и снова — не о том аргументируешь.
Это UI не надо рисовать ручками, поэтому его низкоуровневое представление абсолютно не принципиально.


S>Во-первых, это новый стандарт, требующий разработки отдельного тула, который стоит денег.

Тул идёт в SDK.


S>Во-вторых, этот стандарт сразу ещё более ограниченный, чем даже dialog templates, т.к. не допускает расширения.

Любое расширение означает некий "левый" работающий код. Я уже указывал, что это будет дыра в безопасности.


S>Хорошая платформа — это та, где для объём рукописного кода линеен относительно "площади поверхности".

Забудь про рукописность UI.


S>А в MSI для того, чтобы добавить на форму один контрол, не предусмотренный реляционной структурой, надо полностью отказаться от стандартного UI и воспроизводить и тестировать весь boilerplate руками.
S>С точки зрения пользователя такое решение — спорно. С точки зрения архитектуры — некомпететно.

Бла-бла-бла.
MSI создавался для установки продуктов офиса.
Там полно сложных сценариев и они все покрыты. Если тебе надо указать конкретный инстанс SQL-сервака, то под это дело заводится "символ", т.е. переменная и указывается как параметр, либо, если не указана, то можно дернуть CustomAction для демонстрации юзверю любого диалога. Например, в нашей инсталляхе диалоги были вообще нейтивные, а не дотнетные. Диалогов было несколько и с нетривиальной логикой — вот как раз для указания настроек сервака приложения, с возможностью проверки этих настроек. А для сервака приложений в инсталляхе — указать адрес/инстанс SQL-сервака.

Кароч, ВСЕ, ну т.е. вообще все приведённые тобой контр-примеры — это какой-то детский лепет, который у разработчика занимает не более рабочего дня.

А строить свой пост так, что в каждом абзаце сначала восклицать: "а вы ВООБЩЕ это в ГЛАЗА ВИДЕЛИ?" — это пффф... никогда такого не понимал.
Не видел бы, не давал советов. Я ведь увидел еще тогда, что все советы прошли мимо уха не задерживаясь. Такое ощущение, что или я плохо объясняю, или кого-то совершенно не интересует обсуждаемый предмет, а интересует исключительно подвергнуть MSI обструкции любыми способами. ))



V>>Аналогично языка представления зависимостей. Он полон в декларативном смысле в терминах ВСЕХ объектов, описываемых базой инсталлера. Поэтому, да, некие вещи, выходящие за рамки информации, оперируемой инсталлерами, в нем описать нереально. Но это и хорошо — иначе бы это была дыра в безопасности.
S>Вы сегодня решили побить рекорд плотности чуши на одно сообщение?

Во-во. ЧТД.
АргументЪ!


S>Включение custom action, которые выполняются под elevated privileges — это не дыра в безопасности, а описание в Condition "вещей, выходящих за рамки информации, оперируемой инсталлерами" — дыра? Поздравляю.

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


V>>Мы используем Wise для чего-то уникального и только для совсем типовых пакетов — WiX, так что ничего сказать не могу. Последний раз, когда я пользовался InstallShield в 2003-м, он полностью удовлетворял всем моим нуждам.
S>Это много говорит о ваших нуждах.

Это много говорит о твоей внимательности. Я же предлагал уже решение для твоих проблем с установкой сервиса (у нас была такая же задача) — создаешь проект-заглушку в дотнете с установкой сервиса и перегоняешь полученный пакет в WiX. И вот как раз один из типовых кусков таким образом и нарисовался.


S>Кроме того, в 2003 вы запросто могли использовать InstallShield в режиме wrapper. Был у них такой подход одно время: их самопальный инсталлер тупо заворачивался в один transient компонент в MSI, который был, фактически, только запускальщиком инсталляции.

Ага, и это ты написал после обсуждения сценария установки сервиса в процессе инсталляхи. Прикольно. ))


V>>Я изучал подробно, но для чуть других целей — для целей генерирования скриптов автоматической установки софта.
S>В прошлый раз вы, помнится, "подробно изучали исходники SQL Server".

И?

S>На этот раз вы решили изучить устройство MSI, чтобы научиться писать скрипт, вызывающий msiexec.exe с нужными ключами? Похвально, похвально.

Зачем msiexec.exe? АПИ инсталлера полон, ты можешь сам написать утилиту-аналог msiexec.exe за пару вечеров под основные сценарии. Причем, эту утилиту можно написать на каком-нить скриптовом VBS.


V>>Нет, это ты спросил, как обойтись без ВСЕЙ "наркоманской" базы, я тебе подсказал. Тебе достаточно использовать ту её часть, где реляционное представление как нельзя к месту. Ну вот подыграл твоему "чувству прекрасного", не более того.
S>Ну, безо всей, как выясняется, обойтись нельзя.

Пока что выяснилось, что ты за деревьями не увидел леса. Выбрав в кач-ве основного фокуса приложения усилий WiX, ты не потратил должного времени на изучение структуры таблиц инсталляхи, на изучение COM-АПИ инсталлера, на понимание правил многократного разыменования референсов.

Кароч, ты начал не оттуда. К стадии WiX надо было подходить только освоив все предыдущие стадии. Горе тому, кто пытается пользоваться инструментом под некую предметную область, не понимая самой предметной области. Обезъяна с гранатой, как грится.


S>Вы же в курсе, что если у ваших компонентов есть понятие версии, то без файлов обойтись никак не удастся? Или этот уровень подробностей остался за пределами вашего "подробного изучения"?

Во-во. Нубство как оно есть.
Компонентом может быть что угодно, например, запись в реестре или параметр, который достаётся через кастомную акцию.
Кароч, курить, что есть "компонент".
Понятно, что схватившись сразу за WiX вот эти базовые вещи MSI АПИ остались, как ты там попытался уколоть собеседника?

Или этот уровень подробностей остался за пределами вашего "подробного изучения"?

А ведь "компонент" — это ключевое понятие MSI. Вся остальная шелуха пляшет вокруг "компонента". ))

Версии надо присваивать продуктам, а не компонентам. Ну и все танцы вокруг т.н. "кода обновления" или уникального нового кода, чтобы разные версии жили одновременно, не мешая друг другу.



V>>Ну тогда опять и снова для особо одарённых — я подсказал простой способ получения достоверно работающего результата на имеющемся почти у всех девелоперов инструментарии. Это был ответ на "ай-ай, проблемы с custom actions". )))
S>Вы подсказали простой способ написать hello world. Спасибо, конечно, но этот этап я давно прошёл.

Дык, ты как раз и описывал сложности уровня "hello world", ругая при этом не свои руки, а инструмент. А теперь пытаешься сделать вид, что притворялся. Ты уж определись. ))


V>>Можно подробнее — в чем именно геморрой?
S>В том, чтобы написать custom action, который корректно отрабатывает все режимы.
S>Вы почитайте немножко вот здесь: http://msdn.microsoft.com/en-us/library/aa368070(v=vs.85).aspx

Это не ответ. Тем более это не ответ от тебя, т.к. если ты ручками MSI АПИ не дергал, то не тебе отсылать к доке по нему. ))
Попробуешь еще раз?
Итак, в чем именно геморрой?
Я же описал, как получить "скелет" для грамотно описанной custom actions. Понятное дело, что породить подобный скелет с 0-ля ручками — это застрелиться. А зачем ты так делаешь?


V>>Я понимаю для чего нужен WiX, но вижу непонимание у тебя. Этот DSL всё еще низкоуровневый, он плохо маскирует низлежащую платформу, поэтому пользоваться им напрямую для чего-то повторяемого — глупо.
S>Как раз им и пользуются. В MSI сделать повторно используемый custom action практически невозможно. А в WiX их дофига, и можно добавлять свои: http://wixtoolset.org/documentation/manual/v3/customactions/

Ну ясно. А строил из себя спеца. ))
Я как раз предлагал сваять скелет на MSI и перегнать его в WiX, вычленив необходимое.

Мне этот характер работ очень напоминал мои первые работы в вебе в начале 2000-х, когда только-только начал набирать обороты клиентский скриптинг. Я тогда тупо "тырил" скриптовые снипеты у понравившихся сайтов. Это было быстро и ненапряжно. ))

Аналогично с MSI — точно так тырил из третьесторонних пакетов MSI понравившуюся функциональность.
Пример про скелет установщика сервиса — это было просто пример такого подхода, ес-но.
Но ты намек не понял.