Сообщение Re[12]: [Наброс] Почему нам так нравится разрабатывать фрейм от 22.11.2016 18:54
Изменено 22.11.2016 18:55 vdimas
Здравствуйте, Sinclair, Вы писали:
V>>Для особо упоротых — этот продукт под офис и разрабатывался. А потом стал позиционироваться "для всего".
S>У вас есть какое-то подтверждение этой забавной теории?
Конечно есть — это официальный пресс-релиз Ms Office-2000, где впервые упоминается новый инсталлятор.
Неверующие могут скачать с MSDN-подписки (ну или с торрентов) оригинальный образ дисков этой версии офиса и дополнительно лично убедиться.
V>>По-сути, ты предлагаешь ограничить возможность разработки кастомных контролов. Т.е. надо было дать некую UI-библиотеку сугубо для инсталлера.
S>Нет. Надо было
S>1. Обеспечить совместимость с Dialog Templates для максимизации использования тулчейна
Ну вот я так и думал, что полезных предложений не будет.
Во-первых, давно существуют дизайнеры дизайнер диалогов WI, они ничуть не уступает дизайнеру диалогов Dialog Templates.
А если ты рассуждал о неких "массовых продуктах", то можно было вообще взять что-нить типа этого:
http://www.advancedinstaller.com/download.html
Это копейки, если продукт действительно массовый.
Я уже молчу о куче продуктов попроще, включая тот же WixEdit.
Во-вторых, о совместимости говорить нелепо хотя бы потому, что к контролам в WI можно привязывать некие стандартные действия, а в случае Dialog Templates — нельзя. Ну и набор контролов чуть другой, местами пересекается, местами нет.
В-третьих, сама попытка утверждать, что загвоздка в дизайнере диалогов — это заведомо слить спор. ))
Их было более одного сразу же.
S>2. Обеспечить возможность subclassing и superclassing так же, как в стандартных диалогах — чтобы объём работы зависел от количества нестандартных требований линейно, а не скачкообразно.
Сам не видишь разве, что такие рассуждения попахивают тем, что ты "сабклассил" ручками уникально каждый диалог в нейтивных приложениях, т.е. перехватывал события на стороне parent, без reflection? Не, пару раз и я таким макаром упал-отжался, но исключительно для удовлетворения собственного любопытства.
А если по-делу, то некий GUI-контрол пишется один раз и затем многократно используется.
Но и этого НЕ надо. Когда тебе кажется, что гуйный визард установщика листает некие "вложенные" страницы внутри одного "объемлющего" окошка верхнего уровня — это подлый обман зрения. Каждый диалог создаётся абсолютно с 0-ля, это новый оконный хендл, т.е. новое независимое окно. Общего у них — только хендл текущей инсталляхи. И ты меня что пару лет назад удивлял, что сегодня, показывая непонимание этой простой вещи.
А суть этой простой вещи в том, что возьми, создай свой любой диалог на любой знакомой тебе технологии и дёргай АПИ инсталлера.
Вот ты там спрашивал — а как узнать зависимости, версии и т.д. — да точно так же, как любые другие св-ва.
В наличии есть даже упрощенный вариант COM-библиотеки инсталлера, которую можно юзать из VBScript, основной объект — Session. Вот прямо из этого объекта можно читать некие property, устанавливать их (по результатам работы своих диалогов) и т.д. А эти property потом уже используют последующие custom actions. Т.е. важно отделять действия, которые можно охарактеризовать как install/commit/rollback от действий, которые являются просто "collect some data".
Я как-то просто из VB-скрипта рисовал кастомные диалоги через стандартную ActiveX-библиотеку Microsoft Forms 2.0.
Т.е. разговор ни о чем, проблемы де-факто нет.
Там одна проблема в том, что твои диалоги должны рисоваться уже неким установленным кодом, т.е. нельзя на них "вытащить самого себя за волосы". ))
Ну, дык, уж как минимум один диалог (приветственный) можно сваять на предоставляемой технологии.
S>Ваши предложения по возможной архитектуре UI в Windows Installer я поскипал — там нечего комментировать.
Э, нет, ты ничего не скипал, потому что я НИЧЕГО не предлагал. Я лишь попытался выудить из тебя хоть какой-то конструктив, тип — а что в замен-то? Какую-нить уникальную технологию? Ну вот ты предложил сабкласить окна визарда. Как по мне, то это бред, хотя... кто мешает делать это прямо сейчас? )) Никогда раньше не садился сверху "чужого" диалога, не сабклассил его контролы и не добавлял в диалог установки своих контролов на лету?
Фишка в том, повторюсь — а откуда должен исполняться этот твой кастомный код? Где в этот момент будет располагаться та программа, которая исполняет этот код? Причем, "сабклассить" ограничивает нас нейтивом, пральна?
V>>Ты можешь вообще всё ГУИ инсталлера нарисовать самому и пользоваться MSI API сугубо для того, чтобы дергать ф-ии этого АПИ.
S>При чём здесь MSI API? Я вам о том, что вся структура пакета — бред наркомана.
А уж какой бред наркомана машинный код x86...
Я уже отвечал тебе на это — ты не о том рассуждаешь. Тебе ручками в структуре пакета ковырять не надо, как не надо программировать в машинных кодах. Есть полно высокоуровневых инструментов — SDK, WiX а так же возможность автоматизировать шаги по созданию инсталляхи через COM-скриптинг, что типа:
var installer = new Installer();
var db = installer.OpenDatabase(); // OpenProduct и т.д.
db.Export("Table", "Folder", "File");
db.EnableUIPreview().ViewDialog("Confirm Installation");
А так же можно делать слияние и разделение инсталлях.
Именно через написание своих скриптовых утилит я потом перегонял в WiX и обратно понравившиеся куски других пакетов инсталляций, рефакторил и мёржил их, как тырил когда-то на сайтах клиентский скриптинг, тоже рефакторил и допиливал напильником. )) Потому что в деле программирования "пример использования технологии" — это наипервейшая весчь.
Может, я поэтому с трудостями так и не столкнулся, хотя пришлось обыгрывать сценарии всяко сложнее, озвученных тобой до сих пор. Я всё жду от тебя настоящего challenge. ))
V>>Т.е. ты НИ РАЗУ не передавал как параметр своим custom actions инстанс текущей инсталляхи
S>Что вы называете "инстанс текущей инсталляхи"? hInstall ? Это совсем не то же самое, что инстанс SQL Server. Просто называется похоже.
Угу, способ ухода от прямого ответа — начать разговаривать с самим собой.
"инстанс SQL Server" — это вообще просто строковое св-во в рамках Session.
S>Впрочем, от человека, который путает Skype со Skype for Business, я иного и не ожидал.
Ы? ))
Так ты так и не понял как ты тогда сам себя утопил?
Я ничего не путал. Я говорил о сетевых принципах работы Skype. Ты можешь заходить в конференцию Skype For Business с обычного скайпа. Сюрпрайз? Не знал?
В общем, ты как всегда включил в том споре загадочное лицо и сообщил, что речь у тебя была о веб-версии скайпа. Ну типа уничтожил оппонентов, угу. Правда, тут же сам себя утопил, вспомнив о ссылке-активации на бинарное установленное приложение магазина, что решает проблему доступа в конференцию Скайпа прямо с сайта. Мне осталось лишь поржать и поставить тебе смайл...
А вообще, ты странный тип на этом сайте.
Вроде бы порой говоришь весьма умные вещи. Но чаще даёшь понять, что ты, всё-таки, нифига не программист и никогда им всерьёз не был.
Ну типа как вот эти твои комменты:
Я же говорил тебе — курить, что есть component.
Ну, блин, опытный программист быстро составит себе представление об основных сущностях любой технологии, которой оперирует.
Потому что программист — это циник. А ты не циник, ты мечтатель. Ты любую вещь будешь делать не как надо, не быстро и эффективно, а как тебе внутренне красиво, приятно и вообще "так и должно быть".
Детсад, как по мне.
Или ты там писал, что для того, чтобы к компоненту прикрутить версию, нам обязательно нужен файл.
Это эпик фейл, а не файл. ))
Да, файл может быть частью компонента, но может и не быть. Важно, что у компонента НЕТ версий. Вот нет и всё. Любая твоя "версия" — это чисто прикладная хрень. И если ты способен хоть каким-либо образом закодировать/представить эту "версию" — ну так представь.
И почему именно как файл? А что мешает в виде сетевого запроса твоего сертификата?
А компонент — это всего-навсего минимальная единица транзакции MSI.
Прикручивать версию к единице транзакции — ну это сильно, ИМХО. ))
Компонент же может быть сугубо виртуальный, т.е. не существующий в каком-нить реальном воплощении (по крайней мере в таком воплощении, о котором знает WI), т.к. install, commit и rollback могут быть какими-нить сетевыми запросами или запросами в БД.
Т.е. версию компонента можно сделать и без файла . В любом случае, понятие "версия" здесь получится сугубо прикладное, никак не связанное с иерархией сущностей WI.
Но лучше пользоваться встроенными сущностями инсталлера по-делу, а именно — там, где речь идёт о версиях/апгрейдах и кодах совместимости, использовать сущность Продукт, потому что у него есть ProductCode, в рамках которого уже можно организовать произвольную версионность. Да, иногда удобно, в случае когда один и тот же файл входит в разные продукты, пользоваться понятием версионности этого файла. Но тут сразу твои доводы превращаются в маразм, уж извини — если у нас такой сценарий возможен только для файла, то не стоило пенять на то, что для такого сценария обязательно нужен файл. Тем самым ты показываешь, что ты не программист. Логика того-с. :xz;
Или ты заламывал руки, что вот "а там, ПРЕДСТАВЛЯЕТЕ, несколько ключей продуктов зашито". ))
Это, надо понимать, проявление "продуктофобии"? Да какая тебе разница, сколько ключей продукта зашито?
Ты ты сообщил вслух (и очень зря), что SSL-сертификат у тебя "компонент".
А с какой радости ты, как разработчик, вдруг решил рассматривать его как "компонент"?
Или тут:
"Я гарантирую" что ты подошел к инсталлеру вообще не с той стороны. НЕ понял ни его философии, ни для чего нужны основные сущности инсталлера.
В большинстве случаев задачей custom actions не является копирование чего-то куда-то или установкой флагов в реестре и проч — это даже вредно, потому что в таком случае "чистота" транзакционности инсталлера ложится на плечи автора этих действий. В большинстве случаев тебе надо породить и установить значение некоего текстового property для сессии, продукта, фичи и т.д., которое (значение св-ва) невозможно породить встроенными ср-вами инсталлера. Ну вот, строку подключения к какому-нить кастомному приложению или к БД, например.
Для твоей задачи одно кастомное действие должно было сравнить некую "прикладную версию" SSL сертификата (предположим, его expiration date) с неким встроенным в инсталляху св-вом и в кач-ве результата установить еще какое-нить прикладное св-во, типа "NeedToUpgradeSertificate", по которому далее ветвиться в других шагах инсталляции.
V>>Для особо упоротых — этот продукт под офис и разрабатывался. А потом стал позиционироваться "для всего".
S>У вас есть какое-то подтверждение этой забавной теории?
Конечно есть — это официальный пресс-релиз Ms Office-2000, где впервые упоминается новый инсталлятор.
Неверующие могут скачать с MSDN-подписки (ну или с торрентов) оригинальный образ дисков этой версии офиса и дополнительно лично убедиться.
V>>По-сути, ты предлагаешь ограничить возможность разработки кастомных контролов. Т.е. надо было дать некую UI-библиотеку сугубо для инсталлера.
S>Нет. Надо было
S>1. Обеспечить совместимость с Dialog Templates для максимизации использования тулчейна
Ну вот я так и думал, что полезных предложений не будет.
Во-первых, давно существуют дизайнеры дизайнер диалогов WI, они ничуть не уступает дизайнеру диалогов Dialog Templates.
А если ты рассуждал о неких "массовых продуктах", то можно было вообще взять что-нить типа этого:
http://www.advancedinstaller.com/download.html
Это копейки, если продукт действительно массовый.
Я уже молчу о куче продуктов попроще, включая тот же WixEdit.
Во-вторых, о совместимости говорить нелепо хотя бы потому, что к контролам в WI можно привязывать некие стандартные действия, а в случае Dialog Templates — нельзя. Ну и набор контролов чуть другой, местами пересекается, местами нет.
В-третьих, сама попытка утверждать, что загвоздка в дизайнере диалогов — это заведомо слить спор. ))
Их было более одного сразу же.
S>2. Обеспечить возможность subclassing и superclassing так же, как в стандартных диалогах — чтобы объём работы зависел от количества нестандартных требований линейно, а не скачкообразно.
Сам не видишь разве, что такие рассуждения попахивают тем, что ты "сабклассил" ручками уникально каждый диалог в нейтивных приложениях, т.е. перехватывал события на стороне parent, без reflection? Не, пару раз и я таким макаром упал-отжался, но исключительно для удовлетворения собственного любопытства.
А если по-делу, то некий GUI-контрол пишется один раз и затем многократно используется.
Но и этого НЕ надо. Когда тебе кажется, что гуйный визард установщика листает некие "вложенные" страницы внутри одного "объемлющего" окошка верхнего уровня — это подлый обман зрения. Каждый диалог создаётся абсолютно с 0-ля, это новый оконный хендл, т.е. новое независимое окно. Общего у них — только хендл текущей инсталляхи. И ты меня что пару лет назад удивлял, что сегодня, показывая непонимание этой простой вещи.
А суть этой простой вещи в том, что возьми, создай свой любой диалог на любой знакомой тебе технологии и дёргай АПИ инсталлера.
Вот ты там спрашивал — а как узнать зависимости, версии и т.д. — да точно так же, как любые другие св-ва.
В наличии есть даже упрощенный вариант COM-библиотеки инсталлера, которую можно юзать из VBScript, основной объект — Session. Вот прямо из этого объекта можно читать некие property, устанавливать их (по результатам работы своих диалогов) и т.д. А эти property потом уже используют последующие custom actions. Т.е. важно отделять действия, которые можно охарактеризовать как install/commit/rollback от действий, которые являются просто "collect some data".
Я как-то просто из VB-скрипта рисовал кастомные диалоги через стандартную ActiveX-библиотеку Microsoft Forms 2.0.
Т.е. разговор ни о чем, проблемы де-факто нет.
Там одна проблема в том, что твои диалоги должны рисоваться уже неким установленным кодом, т.е. нельзя на них "вытащить самого себя за волосы". ))
Ну, дык, уж как минимум один диалог (приветственный) можно сваять на предоставляемой технологии.
S>Ваши предложения по возможной архитектуре UI в Windows Installer я поскипал — там нечего комментировать.
Э, нет, ты ничего не скипал, потому что я НИЧЕГО не предлагал. Я лишь попытался выудить из тебя хоть какой-то конструктив, тип — а что в замен-то? Какую-нить уникальную технологию? Ну вот ты предложил сабкласить окна визарда. Как по мне, то это бред, хотя... кто мешает делать это прямо сейчас? )) Никогда раньше не садился сверху "чужого" диалога, не сабклассил его контролы и не добавлял в диалог установки своих контролов на лету?
Фишка в том, повторюсь — а откуда должен исполняться этот твой кастомный код? Где в этот момент будет располагаться та программа, которая исполняет этот код? Причем, "сабклассить" ограничивает нас нейтивом, пральна?
V>>Ты можешь вообще всё ГУИ инсталлера нарисовать самому и пользоваться MSI API сугубо для того, чтобы дергать ф-ии этого АПИ.
S>При чём здесь MSI API? Я вам о том, что вся структура пакета — бред наркомана.
А уж какой бред наркомана машинный код x86...
Я уже отвечал тебе на это — ты не о том рассуждаешь. Тебе ручками в структуре пакета ковырять не надо, как не надо программировать в машинных кодах. Есть полно высокоуровневых инструментов — SDK, WiX а так же возможность автоматизировать шаги по созданию инсталляхи через COM-скриптинг, что типа:
var installer = new Installer();
var db = installer.OpenDatabase(); // OpenProduct и т.д.
db.Export("Table", "Folder", "File");
db.EnableUIPreview().ViewDialog("Confirm Installation");
А так же можно делать слияние и разделение инсталлях.
Именно через написание своих скриптовых утилит я потом перегонял в WiX и обратно понравившиеся куски других пакетов инсталляций, рефакторил и мёржил их, как тырил когда-то на сайтах клиентский скриптинг, тоже рефакторил и допиливал напильником. )) Потому что в деле программирования "пример использования технологии" — это наипервейшая весчь.
Может, я поэтому с трудостями так и не столкнулся, хотя пришлось обыгрывать сценарии всяко сложнее, озвученных тобой до сих пор. Я всё жду от тебя настоящего challenge. ))
V>>Т.е. ты НИ РАЗУ не передавал как параметр своим custom actions инстанс текущей инсталляхи
S>Что вы называете "инстанс текущей инсталляхи"? hInstall ? Это совсем не то же самое, что инстанс SQL Server. Просто называется похоже.
Угу, способ ухода от прямого ответа — начать разговаривать с самим собой.
"инстанс SQL Server" — это вообще просто строковое св-во в рамках Session.
S>Впрочем, от человека, который путает Skype со Skype for Business, я иного и не ожидал.
Ы? ))
Так ты так и не понял как ты тогда сам себя утопил?
Я ничего не путал. Я говорил о сетевых принципах работы Skype. Ты можешь заходить в конференцию Skype For Business с обычного скайпа. Сюрпрайз? Не знал?
В общем, ты как всегда включил в том споре загадочное лицо и сообщил, что речь у тебя была о веб-версии скайпа. Ну типа уничтожил оппонентов, угу. Правда, тут же сам себя утопил, вспомнив о ссылке-активации на бинарное установленное приложение магазина, что решает проблему доступа в конференцию Скайпа прямо с сайта. Мне осталось лишь поржать и поставить тебе смайл...
А вообще, ты странный тип на этом сайте.
Вроде бы порой говоришь весьма умные вещи. Но чаще даёшь понять, что ты, всё-таки, нифига не программист и никогда им всерьёз не был.
Ну типа как вот эти твои комменты:
Компонент имеет версию...Ну, покажите мне, как описать компонент, который имеет версию, определяемую через custom action, и никак не отражён в файловой системе. Что будем писать в KeyPath?
Я же говорил тебе — курить, что есть component.
Ну, блин, опытный программист быстро составит себе представление об основных сущностях любой технологии, которой оперирует.
Потому что программист — это циник. А ты не циник, ты мечтатель. Ты любую вещь будешь делать не как надо, не быстро и эффективно, а как тебе внутренне красиво, приятно и вообще "так и должно быть".
Детсад, как по мне.
Или ты там писал, что для того, чтобы к компоненту прикрутить версию, нам обязательно нужен файл.
Это эпик фейл, а не файл. ))
Да, файл может быть частью компонента, но может и не быть. Важно, что у компонента НЕТ версий. Вот нет и всё. Любая твоя "версия" — это чисто прикладная хрень. И если ты способен хоть каким-либо образом закодировать/представить эту "версию" — ну так представь.
И почему именно как файл? А что мешает в виде сетевого запроса твоего сертификата?
$ echo | openssl s_client -connect google.com:443 2>/dev/null | openssl x509 -noout -dates
notBefore=Jun 19 12:44:04 2013 GMT
notAfter=Oct 31 23:59:59 2013 GMT
А компонент — это всего-навсего минимальная единица транзакции MSI.
Прикручивать версию к единице транзакции — ну это сильно, ИМХО. ))
Компонент же может быть сугубо виртуальный, т.е. не существующий в каком-нить реальном воплощении (по крайней мере в таком воплощении, о котором знает WI), т.к. install, commit и rollback могут быть какими-нить сетевыми запросами или запросами в БД.
Т.е. версию компонента можно сделать и без файла . В любом случае, понятие "версия" здесь получится сугубо прикладное, никак не связанное с иерархией сущностей WI.
Но лучше пользоваться встроенными сущностями инсталлера по-делу, а именно — там, где речь идёт о версиях/апгрейдах и кодах совместимости, использовать сущность Продукт, потому что у него есть ProductCode, в рамках которого уже можно организовать произвольную версионность. Да, иногда удобно, в случае когда один и тот же файл входит в разные продукты, пользоваться понятием версионности этого файла. Но тут сразу твои доводы превращаются в маразм, уж извини — если у нас такой сценарий возможен только для файла, то не стоило пенять на то, что для такого сценария обязательно нужен файл. Тем самым ты показываешь, что ты не программист. Логика того-с. :xz;
Или ты заламывал руки, что вот "а там, ПРЕДСТАВЛЯЕТЕ, несколько ключей продуктов зашито". ))
Это, надо понимать, проявление "продуктофобии"? Да какая тебе разница, сколько ключей продукта зашито?
Ты ты сообщил вслух (и очень зря), что SSL-сертификат у тебя "компонент".
А с какой радости ты, как разработчик, вдруг решил рассматривать его как "компонент"?
Или тут:
Рука-лицо опять.Весь GUI делается в custom action на привычном нам языке, да? Все реальные действия по деплойменту компонентов делаются в custom action, да? Прекрасное подтверждение моего же тезиса.
"Я гарантирую" что ты подошел к инсталлеру вообще не с той стороны. НЕ понял ни его философии, ни для чего нужны основные сущности инсталлера.
В большинстве случаев задачей custom actions не является копирование чего-то куда-то или установкой флагов в реестре и проч — это даже вредно, потому что в таком случае "чистота" транзакционности инсталлера ложится на плечи автора этих действий. В большинстве случаев тебе надо породить и установить значение некоего текстового property для сессии, продукта, фичи и т.д., которое (значение св-ва) невозможно породить встроенными ср-вами инсталлера. Ну вот, строку подключения к какому-нить кастомному приложению или к БД, например.
Для твоей задачи одно кастомное действие должно было сравнить некую "прикладную версию" SSL сертификата (предположим, его expiration date) с неким встроенным в инсталляху св-вом и в кач-ве результата установить еще какое-нить прикладное св-во, типа "NeedToUpgradeSertificate", по которому далее ветвиться в других шагах инсталляции.
Re[12]: [Наброс] Почему нам так нравится разрабатывать фрейм
Здравствуйте, Sinclair, Вы писали:
V>>Для особо упоротых — этот продукт под офис и разрабатывался. А потом стал позиционироваться "для всего".
S>У вас есть какое-то подтверждение этой забавной теории?
Конечно есть — это официальный пресс-релиз Ms Office-2000, где впервые упоминается новый инсталлятор.
Неверующие могут скачать с MSDN-подписки (ну или с торрентов) оригинальный образ дисков этой версии офиса и дополнительно лично убедиться.
V>>По-сути, ты предлагаешь ограничить возможность разработки кастомных контролов. Т.е. надо было дать некую UI-библиотеку сугубо для инсталлера.
S>Нет. Надо было
S>1. Обеспечить совместимость с Dialog Templates для максимизации использования тулчейна
Ну вот я так и думал, что полезных предложений не будет.
Во-первых, давно существуют дизайнеры диалогов WI, они ничуть не уступает дизайнеру диалогов Dialog Templates.
А если ты рассуждал о неких "массовых продуктах", то можно было вообще взять что-нить типа этого:
http://www.advancedinstaller.com/download.html
Это копейки, если продукт действительно массовый.
Я уже молчу о куче продуктов попроще, включая тот же WixEdit.
Во-вторых, о совместимости говорить нелепо хотя бы потому, что к контролам в WI можно привязывать некие стандартные действия, а в случае Dialog Templates — нельзя. Ну и набор контролов чуть другой, местами пересекается, местами нет.
В-третьих, сама попытка утверждать, что загвоздка в дизайнере диалогов — это заведомо слить спор. ))
Их было более одного сразу же.
S>2. Обеспечить возможность subclassing и superclassing так же, как в стандартных диалогах — чтобы объём работы зависел от количества нестандартных требований линейно, а не скачкообразно.
Сам не видишь разве, что такие рассуждения попахивают тем, что ты "сабклассил" ручками уникально каждый диалог в нейтивных приложениях, т.е. перехватывал события на стороне parent, без reflection? Не, пару раз и я таким макаром упал-отжался, но исключительно для удовлетворения собственного любопытства.
А если по-делу, то некий GUI-контрол пишется один раз и затем многократно используется.
Но и этого НЕ надо. Когда тебе кажется, что гуйный визард установщика листает некие "вложенные" страницы внутри одного "объемлющего" окошка верхнего уровня — это подлый обман зрения. Каждый диалог создаётся абсолютно с 0-ля, это новый оконный хендл, т.е. новое независимое окно. Общего у них — только хендл текущей инсталляхи. И ты меня что пару лет назад удивлял, что сегодня, показывая непонимание этой простой вещи.
А суть этой простой вещи в том, что возьми, создай свой любой диалог на любой знакомой тебе технологии и дёргай АПИ инсталлера.
Вот ты там спрашивал — а как узнать зависимости, версии и т.д. — да точно так же, как любые другие св-ва.
В наличии есть даже упрощенный вариант COM-библиотеки инсталлера, которую можно юзать из VBScript, основной объект — Session. Вот прямо из этого объекта можно читать некие property, устанавливать их (по результатам работы своих диалогов) и т.д. А эти property потом уже используют последующие custom actions. Т.е. важно отделять действия, которые можно охарактеризовать как install/commit/rollback от действий, которые являются просто "collect some data".
Я как-то просто из VB-скрипта рисовал кастомные диалоги через стандартную ActiveX-библиотеку Microsoft Forms 2.0.
Т.е. разговор ни о чем, проблемы де-факто нет.
Там одна проблема в том, что твои диалоги должны рисоваться уже неким установленным кодом, т.е. нельзя на них "вытащить самого себя за волосы". ))
Ну, дык, уж как минимум один диалог (приветственный) можно сваять на предоставляемой технологии.
S>Ваши предложения по возможной архитектуре UI в Windows Installer я поскипал — там нечего комментировать.
Э, нет, ты ничего не скипал, потому что я НИЧЕГО не предлагал. Я лишь попытался выудить из тебя хоть какой-то конструктив, тип — а что в замен-то? Какую-нить уникальную технологию? Ну вот ты предложил сабкласить окна визарда. Как по мне, то это бред, хотя... кто мешает делать это прямо сейчас? )) Никогда раньше не садился сверху "чужого" диалога, не сабклассил его контролы и не добавлял в диалог установки своих контролов на лету?
Фишка в том, повторюсь — а откуда должен исполняться этот твой кастомный код? Где в этот момент будет располагаться та программа, которая исполняет этот код? Причем, "сабклассить" ограничивает нас нейтивом, пральна?
V>>Ты можешь вообще всё ГУИ инсталлера нарисовать самому и пользоваться MSI API сугубо для того, чтобы дергать ф-ии этого АПИ.
S>При чём здесь MSI API? Я вам о том, что вся структура пакета — бред наркомана.
А уж какой бред наркомана машинный код x86...
Я уже отвечал тебе на это — ты не о том рассуждаешь. Тебе ручками в структуре пакета ковырять не надо, как не надо программировать в машинных кодах. Есть полно высокоуровневых инструментов — SDK, WiX а так же возможность автоматизировать шаги по созданию инсталляхи через COM-скриптинг, что типа:
var installer = new Installer();
var db = installer.OpenDatabase(); // OpenProduct и т.д.
db.Export("Table", "Folder", "File");
db.EnableUIPreview().ViewDialog("Confirm Installation");
А так же можно делать слияние и разделение инсталлях.
Именно через написание своих скриптовых утилит я потом перегонял в WiX и обратно понравившиеся куски других пакетов инсталляций, рефакторил и мёржил их, как тырил когда-то на сайтах клиентский скриптинг, тоже рефакторил и допиливал напильником. )) Потому что в деле программирования "пример использования технологии" — это наипервейшая весчь.
Может, я поэтому с трудостями так и не столкнулся, хотя пришлось обыгрывать сценарии всяко сложнее, озвученных тобой до сих пор. Я всё жду от тебя настоящего challenge. ))
V>>Т.е. ты НИ РАЗУ не передавал как параметр своим custom actions инстанс текущей инсталляхи
S>Что вы называете "инстанс текущей инсталляхи"? hInstall ? Это совсем не то же самое, что инстанс SQL Server. Просто называется похоже.
Угу, способ ухода от прямого ответа — начать разговаривать с самим собой.
"инстанс SQL Server" — это вообще просто строковое св-во в рамках Session.
S>Впрочем, от человека, который путает Skype со Skype for Business, я иного и не ожидал.
Ы? ))
Так ты так и не понял как ты тогда сам себя утопил?
Я ничего не путал. Я говорил о сетевых принципах работы Skype. Ты можешь заходить в конференцию Skype For Business с обычного скайпа. Сюрпрайз? Не знал?
В общем, ты как всегда включил в том споре загадочное лицо и сообщил, что речь у тебя была о веб-версии скайпа. Ну типа уничтожил оппонентов, угу. Правда, тут же сам себя утопил, вспомнив о ссылке-активации на бинарное установленное приложение магазина, что решает проблему доступа в конференцию Скайпа прямо с сайта. Мне осталось лишь поржать и поставить тебе смайл...
А вообще, ты странный тип на этом сайте.
Вроде бы порой говоришь весьма умные вещи. Но чаще даёшь понять, что ты, всё-таки, нифига не программист и никогда им всерьёз не был.
Ну типа как вот эти твои комменты:
Я же говорил тебе — курить, что есть component.
Ну, блин, опытный программист быстро составит себе представление об основных сущностях любой технологии, которой оперирует.
Потому что программист — это циник. А ты не циник, ты мечтатель. Ты любую вещь будешь делать не как надо, не быстро и эффективно, а как тебе внутренне красиво, приятно и вообще "так и должно быть".
Детсад, как по мне.
Или ты там писал, что для того, чтобы к компоненту прикрутить версию, нам обязательно нужен файл.
Это эпик фейл, а не файл. ))
Да, файл может быть частью компонента, но может и не быть. Важно, что у компонента НЕТ версий. Вот нет и всё. Любая твоя "версия" — это чисто прикладная хрень. И если ты способен хоть каким-либо образом закодировать/представить эту "версию" — ну так представь.
И почему именно как файл? А что мешает в виде сетевого запроса твоего сертификата?
А компонент — это всего-навсего минимальная единица транзакции MSI.
Прикручивать версию к единице транзакции — ну это сильно, ИМХО. ))
Компонент же может быть сугубо виртуальный, т.е. не существующий в каком-нить реальном воплощении (по крайней мере в таком воплощении, о котором знает WI), т.к. install, commit и rollback могут быть какими-нить сетевыми запросами или запросами в БД.
Т.е. версию компонента можно сделать и без файла . В любом случае, понятие "версия" здесь получится сугубо прикладное, никак не связанное с иерархией сущностей WI.
Но лучше пользоваться встроенными сущностями инсталлера по-делу, а именно — там, где речь идёт о версиях/апгрейдах и кодах совместимости, использовать сущность Продукт, потому что у него есть ProductCode, в рамках которого уже можно организовать произвольную версионность. Да, иногда удобно, в случае когда один и тот же файл входит в разные продукты, пользоваться понятием версионности этого файла. Но тут сразу твои доводы превращаются в маразм, уж извини — если у нас такой сценарий возможен только для файла, то не стоило пенять на то, что для такого сценария обязательно нужен файл. Тем самым ты показываешь, что ты не программист. Логика того-с. :xz;
Или ты заламывал руки, что вот "а там, ПРЕДСТАВЛЯЕТЕ, несколько ключей продуктов зашито". ))
Это, надо понимать, проявление "продуктофобии"? Да какая тебе разница, сколько ключей продукта зашито?
Ты ты сообщил вслух (и очень зря), что SSL-сертификат у тебя "компонент".
А с какой радости ты, как разработчик, вдруг решил рассматривать его как "компонент"?
Или тут:
"Я гарантирую" что ты подошел к инсталлеру вообще не с той стороны. НЕ понял ни его философии, ни для чего нужны основные сущности инсталлера.
В большинстве случаев задачей custom actions не является копирование чего-то куда-то или установкой флагов в реестре и проч — это даже вредно, потому что в таком случае "чистота" транзакционности инсталлера ложится на плечи автора этих действий. В большинстве случаев тебе надо породить и установить значение некоего текстового property для сессии, продукта, фичи и т.д., которое (значение св-ва) невозможно породить встроенными ср-вами инсталлера. Ну вот, строку подключения к какому-нить кастомному приложению или к БД, например.
Для твоей задачи одно кастомное действие должно было сравнить некую "прикладную версию" SSL сертификата (предположим, его expiration date) с неким встроенным в инсталляху св-вом и в кач-ве результата установить еще какое-нить прикладное св-во, типа "NeedToUpgradeSertificate", по которому далее ветвиться в других шагах инсталляции.
V>>Для особо упоротых — этот продукт под офис и разрабатывался. А потом стал позиционироваться "для всего".
S>У вас есть какое-то подтверждение этой забавной теории?
Конечно есть — это официальный пресс-релиз Ms Office-2000, где впервые упоминается новый инсталлятор.
Неверующие могут скачать с MSDN-подписки (ну или с торрентов) оригинальный образ дисков этой версии офиса и дополнительно лично убедиться.
V>>По-сути, ты предлагаешь ограничить возможность разработки кастомных контролов. Т.е. надо было дать некую UI-библиотеку сугубо для инсталлера.
S>Нет. Надо было
S>1. Обеспечить совместимость с Dialog Templates для максимизации использования тулчейна
Ну вот я так и думал, что полезных предложений не будет.
Во-первых, давно существуют дизайнеры диалогов WI, они ничуть не уступает дизайнеру диалогов Dialog Templates.
А если ты рассуждал о неких "массовых продуктах", то можно было вообще взять что-нить типа этого:
http://www.advancedinstaller.com/download.html
Это копейки, если продукт действительно массовый.
Я уже молчу о куче продуктов попроще, включая тот же WixEdit.
Во-вторых, о совместимости говорить нелепо хотя бы потому, что к контролам в WI можно привязывать некие стандартные действия, а в случае Dialog Templates — нельзя. Ну и набор контролов чуть другой, местами пересекается, местами нет.
В-третьих, сама попытка утверждать, что загвоздка в дизайнере диалогов — это заведомо слить спор. ))
Их было более одного сразу же.
S>2. Обеспечить возможность subclassing и superclassing так же, как в стандартных диалогах — чтобы объём работы зависел от количества нестандартных требований линейно, а не скачкообразно.
Сам не видишь разве, что такие рассуждения попахивают тем, что ты "сабклассил" ручками уникально каждый диалог в нейтивных приложениях, т.е. перехватывал события на стороне parent, без reflection? Не, пару раз и я таким макаром упал-отжался, но исключительно для удовлетворения собственного любопытства.
А если по-делу, то некий GUI-контрол пишется один раз и затем многократно используется.
Но и этого НЕ надо. Когда тебе кажется, что гуйный визард установщика листает некие "вложенные" страницы внутри одного "объемлющего" окошка верхнего уровня — это подлый обман зрения. Каждый диалог создаётся абсолютно с 0-ля, это новый оконный хендл, т.е. новое независимое окно. Общего у них — только хендл текущей инсталляхи. И ты меня что пару лет назад удивлял, что сегодня, показывая непонимание этой простой вещи.
А суть этой простой вещи в том, что возьми, создай свой любой диалог на любой знакомой тебе технологии и дёргай АПИ инсталлера.
Вот ты там спрашивал — а как узнать зависимости, версии и т.д. — да точно так же, как любые другие св-ва.
В наличии есть даже упрощенный вариант COM-библиотеки инсталлера, которую можно юзать из VBScript, основной объект — Session. Вот прямо из этого объекта можно читать некие property, устанавливать их (по результатам работы своих диалогов) и т.д. А эти property потом уже используют последующие custom actions. Т.е. важно отделять действия, которые можно охарактеризовать как install/commit/rollback от действий, которые являются просто "collect some data".
Я как-то просто из VB-скрипта рисовал кастомные диалоги через стандартную ActiveX-библиотеку Microsoft Forms 2.0.
Т.е. разговор ни о чем, проблемы де-факто нет.
Там одна проблема в том, что твои диалоги должны рисоваться уже неким установленным кодом, т.е. нельзя на них "вытащить самого себя за волосы". ))
Ну, дык, уж как минимум один диалог (приветственный) можно сваять на предоставляемой технологии.
S>Ваши предложения по возможной архитектуре UI в Windows Installer я поскипал — там нечего комментировать.
Э, нет, ты ничего не скипал, потому что я НИЧЕГО не предлагал. Я лишь попытался выудить из тебя хоть какой-то конструктив, тип — а что в замен-то? Какую-нить уникальную технологию? Ну вот ты предложил сабкласить окна визарда. Как по мне, то это бред, хотя... кто мешает делать это прямо сейчас? )) Никогда раньше не садился сверху "чужого" диалога, не сабклассил его контролы и не добавлял в диалог установки своих контролов на лету?
Фишка в том, повторюсь — а откуда должен исполняться этот твой кастомный код? Где в этот момент будет располагаться та программа, которая исполняет этот код? Причем, "сабклассить" ограничивает нас нейтивом, пральна?
V>>Ты можешь вообще всё ГУИ инсталлера нарисовать самому и пользоваться MSI API сугубо для того, чтобы дергать ф-ии этого АПИ.
S>При чём здесь MSI API? Я вам о том, что вся структура пакета — бред наркомана.
А уж какой бред наркомана машинный код x86...
Я уже отвечал тебе на это — ты не о том рассуждаешь. Тебе ручками в структуре пакета ковырять не надо, как не надо программировать в машинных кодах. Есть полно высокоуровневых инструментов — SDK, WiX а так же возможность автоматизировать шаги по созданию инсталляхи через COM-скриптинг, что типа:
var installer = new Installer();
var db = installer.OpenDatabase(); // OpenProduct и т.д.
db.Export("Table", "Folder", "File");
db.EnableUIPreview().ViewDialog("Confirm Installation");
А так же можно делать слияние и разделение инсталлях.
Именно через написание своих скриптовых утилит я потом перегонял в WiX и обратно понравившиеся куски других пакетов инсталляций, рефакторил и мёржил их, как тырил когда-то на сайтах клиентский скриптинг, тоже рефакторил и допиливал напильником. )) Потому что в деле программирования "пример использования технологии" — это наипервейшая весчь.
Может, я поэтому с трудостями так и не столкнулся, хотя пришлось обыгрывать сценарии всяко сложнее, озвученных тобой до сих пор. Я всё жду от тебя настоящего challenge. ))
V>>Т.е. ты НИ РАЗУ не передавал как параметр своим custom actions инстанс текущей инсталляхи
S>Что вы называете "инстанс текущей инсталляхи"? hInstall ? Это совсем не то же самое, что инстанс SQL Server. Просто называется похоже.
Угу, способ ухода от прямого ответа — начать разговаривать с самим собой.
"инстанс SQL Server" — это вообще просто строковое св-во в рамках Session.
S>Впрочем, от человека, который путает Skype со Skype for Business, я иного и не ожидал.
Ы? ))
Так ты так и не понял как ты тогда сам себя утопил?
Я ничего не путал. Я говорил о сетевых принципах работы Skype. Ты можешь заходить в конференцию Skype For Business с обычного скайпа. Сюрпрайз? Не знал?
В общем, ты как всегда включил в том споре загадочное лицо и сообщил, что речь у тебя была о веб-версии скайпа. Ну типа уничтожил оппонентов, угу. Правда, тут же сам себя утопил, вспомнив о ссылке-активации на бинарное установленное приложение магазина, что решает проблему доступа в конференцию Скайпа прямо с сайта. Мне осталось лишь поржать и поставить тебе смайл...
А вообще, ты странный тип на этом сайте.
Вроде бы порой говоришь весьма умные вещи. Но чаще даёшь понять, что ты, всё-таки, нифига не программист и никогда им всерьёз не был.
Ну типа как вот эти твои комменты:
Компонент имеет версию...Ну, покажите мне, как описать компонент, который имеет версию, определяемую через custom action, и никак не отражён в файловой системе. Что будем писать в KeyPath?
Я же говорил тебе — курить, что есть component.
Ну, блин, опытный программист быстро составит себе представление об основных сущностях любой технологии, которой оперирует.
Потому что программист — это циник. А ты не циник, ты мечтатель. Ты любую вещь будешь делать не как надо, не быстро и эффективно, а как тебе внутренне красиво, приятно и вообще "так и должно быть".
Детсад, как по мне.
Или ты там писал, что для того, чтобы к компоненту прикрутить версию, нам обязательно нужен файл.
Это эпик фейл, а не файл. ))
Да, файл может быть частью компонента, но может и не быть. Важно, что у компонента НЕТ версий. Вот нет и всё. Любая твоя "версия" — это чисто прикладная хрень. И если ты способен хоть каким-либо образом закодировать/представить эту "версию" — ну так представь.
И почему именно как файл? А что мешает в виде сетевого запроса твоего сертификата?
$ echo | openssl s_client -connect google.com:443 2>/dev/null | openssl x509 -noout -dates
notBefore=Jun 19 12:44:04 2013 GMT
notAfter=Oct 31 23:59:59 2013 GMT
А компонент — это всего-навсего минимальная единица транзакции MSI.
Прикручивать версию к единице транзакции — ну это сильно, ИМХО. ))
Компонент же может быть сугубо виртуальный, т.е. не существующий в каком-нить реальном воплощении (по крайней мере в таком воплощении, о котором знает WI), т.к. install, commit и rollback могут быть какими-нить сетевыми запросами или запросами в БД.
Т.е. версию компонента можно сделать и без файла . В любом случае, понятие "версия" здесь получится сугубо прикладное, никак не связанное с иерархией сущностей WI.
Но лучше пользоваться встроенными сущностями инсталлера по-делу, а именно — там, где речь идёт о версиях/апгрейдах и кодах совместимости, использовать сущность Продукт, потому что у него есть ProductCode, в рамках которого уже можно организовать произвольную версионность. Да, иногда удобно, в случае когда один и тот же файл входит в разные продукты, пользоваться понятием версионности этого файла. Но тут сразу твои доводы превращаются в маразм, уж извини — если у нас такой сценарий возможен только для файла, то не стоило пенять на то, что для такого сценария обязательно нужен файл. Тем самым ты показываешь, что ты не программист. Логика того-с. :xz;
Или ты заламывал руки, что вот "а там, ПРЕДСТАВЛЯЕТЕ, несколько ключей продуктов зашито". ))
Это, надо понимать, проявление "продуктофобии"? Да какая тебе разница, сколько ключей продукта зашито?
Ты ты сообщил вслух (и очень зря), что SSL-сертификат у тебя "компонент".
А с какой радости ты, как разработчик, вдруг решил рассматривать его как "компонент"?
Или тут:
Рука-лицо опять.Весь GUI делается в custom action на привычном нам языке, да? Все реальные действия по деплойменту компонентов делаются в custom action, да? Прекрасное подтверждение моего же тезиса.
"Я гарантирую" что ты подошел к инсталлеру вообще не с той стороны. НЕ понял ни его философии, ни для чего нужны основные сущности инсталлера.
В большинстве случаев задачей custom actions не является копирование чего-то куда-то или установкой флагов в реестре и проч — это даже вредно, потому что в таком случае "чистота" транзакционности инсталлера ложится на плечи автора этих действий. В большинстве случаев тебе надо породить и установить значение некоего текстового property для сессии, продукта, фичи и т.д., которое (значение св-ва) невозможно породить встроенными ср-вами инсталлера. Ну вот, строку подключения к какому-нить кастомному приложению или к БД, например.
Для твоей задачи одно кастомное действие должно было сравнить некую "прикладную версию" SSL сертификата (предположим, его expiration date) с неким встроенным в инсталляху св-вом и в кач-ве результата установить еще какое-нить прикладное св-во, типа "NeedToUpgradeSertificate", по которому далее ветвиться в других шагах инсталляции.