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

S>Это всё здорово, если бы в нагрузку не шла реляционная база данных.



Ну, право, это как критиковать сегодня морально устаревший набор кодов Интел-совместимых процессоров, со всеми их расширениями SSEx, где итоговая бинарная кодировка одна из САМЫХ НЕОПТИМАЛЬНЫХ В ИНДУСТРИИ! И чё??? Да ничё. Все понимают, никто и не спорит, но это никого не парит.


V>>Еще раз для особо одаренных. Изначально был расчет на коммерческие приложения, где это, действительно, несложно.
S>Ещё раз для особо одарённых: это несложно для того сценария, в котором база данных не нужна вообще, от слова совсем.

Ну, вообще-то, в той информации достоверно прослеживаются уникальные ключи и связи. Таки стоит взглянуть на схему базы — она относительно несложная. Т.е. реляции предоставляются предметной областью, поэтому огульно высмеять её не получится никак, увы. Можно лишь поспорить относительно отдельных таблиц и связей. Я соглашусь только с иронией по поводу представления UI, но блин, в сотый раз оговорюсь, что эта ирония бессмыслена изначально, бо с выходом самой первой версии инсталлера в его SDK был тул по визуальному редактированию и тестированию UI. Более того, диалоги из разных пакетов можно склеивать в один целевой, то бишь некая контора вполне может хранить однажды разработанные диалоги в кач-ве библиотек.

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

Кароч, извините за самоповтор, но вся эта критика пока на уровне критики объектных кодов Интел-совместимых процессоров.

V>>Он фигню написал, ваще-то. Это как призывы писать программы на ассемблере. ))
S>Фигню пока что пишете исключительно вы. Вы сами-то хоть раз installshield запускали?
S>Там все эти install condition-ы пишутся точно так же, как в Orca — только не надо наизусть названия табличек знать. Вы попробуйте написать инсталлятор для веб-приложения, которое может ставиться в нескольких экземплярах на одном сервере, требует в зависимостях определённых фич IIS и наличия SQL Server Reporting Services, в который деплоятся (или апгрейдятся) репорты.
S>Я вас уверяю — коробку с InstallShield вы отнесёте на помоечку, и поставите себе WiX.

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

S>И будете изучать структуру MSI, а вашим лучшим другом станет Orca.

Я изучал подробно, но для чуть других целей — для целей генерирования скриптов автоматической установки софта.

V>>Опиши в MSI только продукты и компоненты. Не возись с файлами, зависимостями и прочей "наркоманией", если не хочешь.
V>>Перехвати требуемые custom actions и пусть в них работают твои bat-скрипты.
S>Круто. Вот это как раз и есть требование писать на асемблере. То есть все эти чудо-таблицы, получается, не нужны. Весь GUI делается в custom action на привычном нам языке, да? Все реальные действия по деплойменту компонентов делаются в custom action, да? Прекрасное подтверждение моего же тезиса.

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


S>Сразу видно человека, который custom action никогда в жизни не писал.

Сразу видно человека с проблемной самооценкой.


V>>Если у кого-то проблемы с руками и custom actions... блин, пусть создадут пустое приложение Windows Service на дотнете в студии, добавят к нему инсталлер сервиса, потом сделают пакет с ним и разберут получившийся MSI каким-нить просмотрщиком или экспортером в WiX. Это порядка 5-10 мин всех делов.
S> В отличие от вас, коллега, я (и, судя по всему, коллега Нахлобуч) провели немало часов "разбирая получившийся MSI" от разных инсталлер-генераторов. И от студийного, и от инсталлшилдовского, и от викса.

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

Более того, именно так я когда-то сделал себе "скелет" пакета, когда надо было накидать по-быстрому инсталляшку нейтивного сервиса. Всё получилось за считанные минуты.


V>>Там не одна логика, а целый букет:
V>>- инсталляция
V>>- реинсталляция/восстановление
V>>- инсталляция по-требованию
V>>- деинсталляция
V>>- добавить компонент
V>>- убрать компонент
V>>- собрать инфо о пользователе
V>>- ...
S>Дупа в том, что встроенные действия, которые поддерживают всё вот это, крайне ограничены. А кастомные писать — геморрой. Как раз потому, что про них авторы мегаархитектуры думали меньше всего.

Можно подробнее — в чем именно геморрой?
Основной геммор как по мне — это в довольно большом кол-ве пропертей (некоторые из которых необходимо "разыменовать" как указатели, иногда более одного раза), но ими НЕОБХОДИМО оперировать, если пишешь вменяемый custom action. Дык, это как бы часть предметной области, не? Например, писал пакеты под RPM — там тоже дохренищща подобной предметной области. Се ля ви. И тут уже реляционность или объектность базы до одного места. ИМХО, наоборот, в реляционной базе доставать/разыменовывать пропертя удобнее, бо однотипнее, автоматизируется несложной однажды написанной либой.

V>>"Просто описать логику" можно лишь по каждой отдельной строчке. Дык, опиши! Твоя задача будет лишь дать имя/ключ продукту/компонентам и назначить всю ту "простую логику инсталляции" по соотв событиям. А если ты потратил хотя бы день-два на эту тему, то в твоём "просто описании" будет ветвление по пропертям, например, учет того факта: UI-инсталляция или silent, а так же уровень этого UI, административная инсталляция или локальная, на текущего юзера или на всех и т.д. и т.п.
S>В моём "просто описании" будет ветвление по тем пропертям, которые мне нужны. Если оно вообще нужно.
S>И в моём "просто описании" не будет этого колоссального разрыва между встроенной и продукто-специфичной логикой.
S>Собственно, WiX и есть попытка сделать DSL для платформы с идиотским дизайном. А то, что вы его не понимаете, показывает только то, что вы в жизни не сталкивались с разработкой инсталляторов для более-менее массовых продуктов.

Я понимаю для чего нужен WiX, но вижу непонимание у тебя. Этот DSL всё еще низкоуровневый, он плохо маскирует низлежащую платформу, поэтому пользоваться им напрямую для чего-то повторяемого — глупо. У нас, например, WiX генерится с помощью своих скриптов для однотипных пакетов. Дарю идею, как грится. )))

В личке могу дать ссылки на вполне себе востребованные продукты. Не уверен что оно тебе надо, конечно... ХЗ что у тебя за проблемы с самооценкой на почти пятом десятке, но от выделенного несет просто комплексами какими-то. Позволю себе впредь игнорить подобный информационный мусор.