Re[4]: [Наброс] Почему нам так нравится разрабатывать фреймворки и платформы?
От: vdimas Россия  
Дата: 12.05.14 23:12
Оценка: +1 :)
Здравствуйте, 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 -> бинарный образ) и никак иначе.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.