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

CS>Например из тех что я знаю достоверно Amazon, Google, Twitter, Facebook, Microsoft и т.д.

Сначала продукт, потом фреймворк. Все без исключения.

Здравствуйте, Нахлобуч, Вы писали:

V>>Есть некий АПИ инсталлера, а есть к нему "движок", в котором можно закодировать вызовы этого АПИ декларативным способом. Классика декларативного подхода — описание зависимостей. Всё.

Н>Начнем издали: насколько плотно ты работал с MSI и видел ли, как он устроен изнутри?

Начнем издали: насколько плотно ты знаешь АПИ инсталлера? Работал ли с ним напрямую (например, через скриптинг), или только через "проигрывание" MSI-пакета?
Какими высокоуровневыми инструментами пользовался?

Просто весь этот WiX, которым тычут как адовым адом — это как ассемблер. Но отсюда некоторые горячие головы делают далеко идущие выводы.

А если рассмотреть отношения внутри самой базы MSI — там не так уж много таблиц (в сравнении со средней прикладной базой), я не вижу особой сложности изучить её тем, кто делает инструментарий под MSI. Любые рассуждения о сложности отношений внутри пакета MSI — натуральный детсад. У нас с этим разбирались даже вчерашние студенты.

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

Сталкивался с этим, на своем опыте. Пишем фреймворк который по замыслу позволит быстро решить задачу, но при работе с ним выясняется, что в нем то чего то не хватает, то некоторые вещи можно было бы сделать "по прямее". Добавляем, выпрямляем, дальше используем. Лучше сначала задачу решить и возможно не одну, а уже потом придумывать под это дело фреймворк.

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

V>Просто весь этот WiX, которым тычут как адовым адом — это как ассемблер. Но отсюда некоторые горячие головы делают далеко идущие выводы.

Про WiX тут ни слова не сказалось еще, это своя отдельная песня.

V>А если рассмотреть отношения внутри самой базы MSI — там не так уж много таблиц (в сравнении со средней прикладной базой), я не вижу особой сложности изучить её тем, кто делает инструментарий под MSI. Любые рассуждения о сложности отношений внутри пакета MSI — натуральный детсад. У нас с этим разбирались даже вчерашние студенты.

Сама по себе идея декларативного описания целевого состояния системы вполне имеет право на жизнь. "Слышь, Windows Installer, сделай так, чтобы вот тут появилась папка с файлами, необходимыми для того, чтобы работали выбранные пользователем Feature'ы, чтобы в реестре были вот такие ключи и в меню Start появились вот эти ярлыки. Как ты этого добьешься -- мне не интересно".

Идея, повторюсь, здравая. Но вот реализация подвела.

Индусы-астронавты, которым поручили написать установщик для Офиса, нашли новый энтерпрайз-молоток: COM Structured Storage и кровного брата его, Compound File. И решили они сочинить на этой почве подобие БД, да не абы какое, а Column-Oriented, чтоб с подвыподвертом. И все заверте...

Установщик должен делать что? Правильно, устанавливать. А что ему надо устанавливать? О, это вопрос очень сложный и к нему надо подойти ответственно. Значицца, сначала надо перекопать весь реестр на предмет наличия предыдущих версий, затем запустить процесс File Costing'а, чтобы покомпонентно понять, сколько же места займет неведомое нечто, только потом спросить у пользователя, что и куда он будет устанавливать, потом еще похрустеть шпинделями, выполняя совершенно логично именованные Custom Action Type 35, 36, 37 и 38, подготовить скрипт и торжественно его накатить. В пылу совершенно забыли о зависимостях, ну да с кем не бывает.

Всю информацию для выполнения этих священных пассов архитекторы в мудрости своей решили растолкать по таблицам, структуру и имена которым придумывал самый экономный индус: CCPSearch, CompLocator, DrLocator, SFPCatalog. Поведение задавалось декларативно.

Как уже стало понятно из емкого названия "DrLocator", каждый байт был на счету. Поэтому придумали Install-On-Demand (потому что без этого инсталлятор получался слишком понятным, недостаточно сложным и там было слишком мало ошибок), патчи, Merge Module'ы и прочие захватывающие вещи.

После того, как достаточно хорошо запутали сам процесс установки, настало время переходить к UI.

Вместо того, чтобы хранить описание пользовательского интерфейса в, например Resource-файлах, для которых уже есть нормальные существующие редакторы (или в XML; энтерпрайз же), его решили хранить в таблице. А поскольку у них не Монго какое-нибудь, а настоящая база данных, то для каждого типа элемента управления запилили свою таблицу: Dialog, Control, Checkbox, RadioButton, ListBox, Billboard, BBControl, ListView и т.д.

А потом выяснилось, что кнопочки-то надо включать-отключать в зависимости от внешних пендалей, и появилась таблица ControlCondition, где на птичьем языке Condition Statement'ов декларативно, черт побери, задаются всяческие условия.

Почетное право Condition Statement'ы доверили какому-то укурку, потому что тот ад, который творится и в синтаксисе, и в семантике, ничем иным объяснить нельзя.

Затем стало понятно, что нажатие на кнопочки должно к чему-то осязаемому приводить, и придумали декларативную подписку на события, где в экстазе сошлись Condition Statement'ы вида "(OutOfDiskSpace = 1 AND OutOfNoRbDiskSpace = 1) OR (OutOfDiskSpace = 1 AND PROMPTROLLBACKCOST="F")" и гигантский список событий, доступный не абы как, а с различными оговорками. Чтобы все это вместе связать пришлось синей изолентой прикрутить декларативную же этих событий публикацию.

Чтобы все это сооружение из говна и палок не рассыпалось под собственным весом, были сочинены сто с лишним ICE-проверок, потому что а ну как же иначе?

И вот эту священную корову и выкатили на потеху публике.

Здравствуйте, Нахлобуч, Вы писали:

Прежде чем отвечать, тебе следовало бы ответить на самый первый вопрос того поста, на который ты отвечаешь. Само АПИ инсталлера очень удобное и очень последовательное. Движок проигрывания MSI-файлов можно рассматривать как надстройку. Что-то типа как XML описание UI для некоего UI-движка. Вполне можно писать самим или генерировать императивный скрипт. Некоторые инсталляторы используют свои собственные форматы мета-описания.

Все обобщенные высказывания не соответствуют действительности.
В том числе и это.

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

M>Я бы добавил еще недооценку сложности проблемы и переоценку собственных сил.
+500

M>Ну и мозг подставляет подножку своим умением натягивать сову на глобус. Изучив 5-10% описания проекта, мозг подгоняет оставшееся под уже привычные шаблоны, в результате чего возникает ощущение, что создание framework-а это просто самый рациональный быстрый способ создания программного продукта. А потом оказывается, что абстракции, которые в первом приближении так идеально отвечали всем потребностям проекта, ни фига не работают. Попытка решить одним потоком управления несколько разных задачи приводит к классической дилемме "хвост вытащишь — нос воткнешь, нос вытащишь — хвост воткнешь".
Увы, есть такое. Желание творить часто искушает неокрепшие души

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

CS>У меня несколько противоположный опыт.
CS>Все успешные и серьезные компании которые имеют какой-нибудь успех используют свои собственные frameworks и platforms.
Заметь, это успешные компании и успешные фреймворки
Я же говорил не о них, а о том мыслительном процессе, который приводит к появлению провальных фреймворков и проектов.

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

M>Все обобщенные высказывания не соответствуют действительности.
M>В том числе и это.
Абсолютно согласен.
Как это относится к моей гипотезе?

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

L>Ну ведь можно не писать "фреймверк", а писать библиотеки, решающие только одну задачу, а гибкость получать за счет комбинирования таких библиотек.

+1, буквально недавно это обсуждали

Автор: Evgeny.Panasyuk
Дата: 25.04.14

:

EP>Мне вот интересно, как и откуда появился феномен тяги Java'истов к framework'ам? Поясню:
EP>Есть библиотеки — наборы готовых компонент, функций, структур данных, алгоритмов и т.п. Их легко применять — они не влияют на общую структуру приложения, полностью ортогональны, т.е. никак не мешают друг на другу. Это, грубо говоря, рабочие инструменты — как молоток или пила.
EP>А есть фрейморки — в буквальном смысле типовой "каркас" приложения (или его часть). Фрейморки более тяжёлые, громоздкие, неповоротливые и зачастую несовместимые. Но если вся структура приложения, либо его часть, достаточно типовое — то тут действительно применение готового каркаса, по "типовому проекту" — вполне оправданно.

M>>Все обобщенные высказывания не соответствуют действительности.
M>>В том числе и это.
0>Абсолютно согласен.
0>Как это относится к моей гипотезе?

К гипотезе — никак. Относится к заголовку.
Мне, например (а под "нам" в заголовке я понял и себя в том числе), не нравится.

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

V>Да че за бред-то???
Спасибо за то, что вы, коллега, как обычно влезли в тему, в которой плохо разбираетесь.

V>Есть некий АПИ инсталлера,
Это вы, надо полагать, имеете в виду вот это: http://msdn.microsoft.com/en-us/library/aa369426(v=vs.85).aspx
V>а есть к нему "движок", в котором можно закодировать вызовы этого АПИ декларативным способом
Это вы, надо полагать, имеете в виду вот это: http://msdn.microsoft.com/en-us/library/aa369398(v=vs.85).aspx

V>Ну и изначально расчет был на высокоуровневый инструментарий и этого инструментария хватает, удобного. Другое дело, что он платный. Дык, это другая тема уже.
На какой "высокоуровневый инструментарий" вы намекаете? На WiX что ли? Или на Orca?

Весь "API инсталлера" — высокоуровневый, он полагается на содержимое базы данных. Рассматривать его в отрыве от MSI не имеет смысла.
А устройство базы данных является вполне наглядной иллюстрацией моего тезиса: авторы замахнулись на то, что прикладным программистам не нужно будет писать код инсталлятора (чтобы понять, что такое "код инсталлятора", можно посмотреть на более-менее старый InstallShield. Там пацаны ударились в другую крайность: в 2005 примерно году они на полном серьёзе предлагали писать цикл обработки очереди сообщений вручную), а достаточно будет просто "корректно заполнить таблички в базе".
Про то, что "заполнить таблички в базе" даже для примитивного случая CD-ejector представляет собой нетривиальную задачу, уже написал коллега Нахлобуч. Оказывается, что в таких случаях даже инсталлер на bat-файлах будет проще в разработке и поддержке.
А во всех остальных случаях разработчики вынуждены бороться с этой адовой наркоманией, чтобы заставить свои custom actions корректно работать. Вместо того, чтобы просто написать логику инсталляции на каком-нибудь приемлемом языке программирования.

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

V>Прежде чем отвечать, тебе следовало бы ответить на самый первый вопрос того поста, на который ты отвечаешь. Само АПИ инсталлера очень удобное и очень последовательное. Движок проигрывания MSI-файлов можно рассматривать как надстройку.

То есть, ты хочешь сказать, что есть некие "альтернативные движки", которые хранят данные в каком-то своем чистом и непорочном формате, а какие-то розовые пони просто дергают функции MsiXXX?

Извини, но не поверю. Весь API MSI, во-первых, пронизан MSIHANDLE hInstall'ами и прочими LPCTSTR szProduct'ами, которые какбэ намекают на то, что кроме как с пакетами MSI все это добро работать не умеет, а, во-вторых, представляет собой такую же непродираемую кашу из висящих где-то там в эфире сессий, транзакций, хэндлов, текстовых названий Feature'ов и прочего хлама.

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

0>Я неоднократно видел одну и ту же ситуацию — вместо разработки решения для конкретной бизнес-задачи команда начинает пилить обобщенное техническое решение, платформу или каркас. Обычно это подается под соусом снижения затрат на будущие разработки, дескать, сейчас "наработаем технологию" (или даже "наработаем архитектуру"), а потом на ее основе за три дня слепим конечный продукт. А потом и еще десяток, если надо будет.

Есть общая тендеция — уход от реальности
1. игнорируется перспектива, решения исключительно "здесь и сейчас" — фремворк чисто условно
2. игнорируется текущее состояние — future coding на марше, все ради фремворка, даже если нужно решать текущие срочные проблемы

Среди разработчиков есть и те и другие, при чем не всегда ясно, каких больше.

Важно, что в обоих случаях и те и другие откладывают решение реальных проблем. В первом случае проявляется так — добавление одной функции ломает всё подряд. Во втором — готово 90%, осталось еще 90%.

Причины ухода от реальности самые разные: инфантильность, зависимое поведение, уход от ответсвенности, страх, неадекватная самооценка, неадекватные ожидания и тд.

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

I>Есть общая тендеция — уход от реальности

В большинстве случаев это не уход от реальности, а просто изначальное отсутствие контакта с ней.
Культ карго. Копируют в меру своего понимания действия профи, а поскольку понимание убогое, то и результат соответствующий.

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

V>>Ну и изначально расчет был на высокоуровневый инструментарий и этого инструментария хватает, удобного. Другое дело, что он платный. Дык, это другая тема уже.
S>На какой "высокоуровневый инструментарий" вы намекаете? На WiX что ли? Или на Orca?

Любой, где можно накидать пакет мышкой, навроде InstallShield, Wise, VisualInstaller и т.д.
А так же компонент студии, который вернули в VS 2013.

S>Весь "API инсталлера" — высокоуровневый, он полагается на содержимое базы данных. Рассматривать его в отрыве от MSI не имеет смысла.

Имеет аж бегом.
Основная польза от MSI-АПИ в иерархии продукт -> компонент.
В автоматическом учете компонентов (счетчики), при пользовании ими из разных продуктов.
В транзакционности инсталляции.
В возможности инсталляции по-требованию.
В стандартизации основных сценариев инсталляции.
В учете сырцов-медиа инсталляций.
И т.д.

S>А устройство базы данных является вполне наглядной иллюстрацией моего тезиса: авторы замахнулись на то, что прикладным программистам не нужно будет писать код инсталлятора (чтобы понять, что такое "код инсталлятора", можно посмотреть на более-менее старый InstallShield. Там пацаны ударились в другую крайность: в 2005 примерно году они на полном серьёзе предлагали писать цикл обработки очереди сообщений вручную), а достаточно будет просто "корректно заполнить таблички в базе".

Еще раз для особо одаренных. Изначально был расчет на коммерческие приложения, где это, действительно, несложно. Уже в 7-й студии шли встроенные проекты-инсталлеры (урезанный вариант платного). До семерки были аналогичные платные плагины. Т.е. я вообще не понимаю, о чем тут заламывание рук, если еще в 2000-м году это было де-факто было элементарно на имеющемся инструментарии.


S>Про то, что "заполнить таблички в базе" даже для примитивного случая CD-ejector представляет собой нетривиальную задачу, уже написал коллега Нахлобуч.

Он фигню написал, ваще-то. Это как призывы писать программы на ассемблере. ))
Пишите, если нравится.
А если он из тех, кто разрабатывает эти самые VisualInstaller и Co, то он вас просто злобно троллит. Это не бог весь какая сложная область для написания инструментария к ней.

S>Оказывается, что в таких случаях даже инсталлер на bat-файлах будет проще в разработке и поддержке.
S>А во всех остальных случаях разработчики вынуждены бороться с этой адовой наркоманией, чтобы заставить свои custom actions корректно работать.

Мдее...
Опиши в MSI только продукты и компоненты. Не возись с файлами, зависимостями и прочей "наркоманией", если не хочешь.
Перехвати требуемые custom actions и пусть в них работают твои bat-скрипты.

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

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


S>Вместо того, чтобы просто написать логику инсталляции на каком-нибудь приемлемом языке программирования.

Там не одна логика, а целый букет:
— инсталляция
— реинсталляция/восстановление
— инсталляция по-требованию
— деинсталляция
— добавить компонент
— убрать компонент
— собрать инфо о пользователе
— ...

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

=========
Как по мне, то наркоманией является WiX. Если писать в базу MSI — это как программировать в кодах, то WiX — ассемблер. Его можно использовать исключительно как бэкенд какого-нить высокоуровневого тулза/скрипта (например, в цепочке: высокоуровневое представление -> промежуточное представление WiX -> бинарный образ) и никак иначе.

Здравствуйте, vdimas, Вы писали:
V>Любой, где можно накидать пакет мышкой, навроде InstallShield, Wise, VisualInstaller и т.д.
Практика показывает, что ни в чём из этого "накидать пакет мышкой" невозможно. Кроме случаев, когда продукт вообще поддерживает copy deployment, и никакой "инсталлятор" ему вообще не нужен.
V>Имеет аж бегом.
Вы для начала его запустите без MSI-файла, а потом поговорим о беге и прочем.

V>Основная польза от MSI-АПИ в иерархии продукт -> компонент.
И от этой же иерархии — основной вред. Вы в курсе, как устроен инсталлятор MS SQL Server, начиная примерно с 8.0? Если нет — то вот вам домашнее задание: выразить в терминах Windows Installer сосуществование нескольких инстансов SQL Server, при этом они могут быть как различных версий, так и одинаковых.

V>В автоматическом учете компонентов (счетчики), при пользовании ими из разных продуктов.
V>В транзакционности инсталляции.
V>В возможности инсталляции по-требованию.
V>В стандартизации основных сценариев инсталляции.
V>В учете сырцов-медиа инсталляций.
V>И т.д.
Это всё здорово, если бы в нагрузку не шла реляционная база данных.

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

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

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

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

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

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