> Почему нам так нравится разрабатывать фреймворки и платформы?

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

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

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

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

Ну и, во-вторых, при разработке фреймворков и платформ у программиста гораздо больше шансов поучаствовать в постановке задачи и принятии решений о необходимых компромиссах, и, соответственно, меньше шансов необходимости наступать на собственное чувство прекрасного и скрежетать зубами на тему "какого хрена они (без меня) решили, что это нужно делать именно так, а не иначе?!" (Еще одна перманентная боль бизнес-лоджик-кодеров — прикладников. В "они" попадают и системщики, и бизнес-аналитики.)

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

P>Раз уж тему подняли...
P>На самом деле™, если команда получает готовый фреймворк, она не начинает делать с его помощью целевую задачу. Вместо этого во фреймворке находят кучу недостатков и начинают активно их исправлять.
Ну, конечно же, ведь в готовом фреймворке, очевидно, есть фатальный недостаток™

P>Я тоже участвовал. Проект в конечном итоге запустили. Но времени это затребовало на 2.5 года больше, чем планировалось. Мне в результате все эти 2.5 года пришлось параллельно тащить старый проект, что-то в нем постоянно допиливая и исправляя.
Знакомая картина.
Кстати, проект из п.3. примерно так и завернул — решено спешно реанимировать прошлую версию, чтобы было что продавать

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

0>Зло, о котором я говорю — это именно такой подход, а не результат.
Видел тоже самое.
0>Вообщем, наброс сделан, жду ваших мнений
Это сродни графомании, т.е. проблема в конкретных людях которые потакают конкретным проблемам своей психики. Возможно, такое связано с идеалистическими и/или перфекционистическими взглядами, либо банальной прокрастинацией и неуменеим завершать задачу. Возможно, под этим соусом подаётся неумение показать реальный рещультат, ведь всегда на вопрос "что ты делаешь" можно ответить "пилю фреймворк", а в реальности ничего что работало бы и не видно, ха-ха!

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

K>Это сродни графомании, т.е. проблема в конкретных людях которые потакают конкретным проблемам своей психики. Возможно, такое связано с идеалистическими и/или перфекционистическими взглядами, либо банальной прокрастинацией и неуменеим завершать задачу. Возможно, под этим соусом подаётся неумение показать реальный рещультат, ведь всегда на вопрос "что ты делаешь" можно ответить "пилю фреймворк", а в реальности ничего что работало бы и не видно, ха-ха!
По моему мнению, это в первую очередь узость картины мира, куда не попадает ответ на вопрос "зачем это вообще делается?"
Подобные извороты всегда я наблюдал именно тогда, когда разработка варилась в собственном соку, выдумывая себе критерии успеха, а не соотнося их с потребностями бизнеса.

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

0>>Вообщем, наброс сделан, жду ваших мнений
A>Как только программист глядя на описание новой фичи задаёт вопрос "зачем?", его тут же выгоняют в тимлиды, а потом в менеджеры проектов. Программистами остаются только те, кого интересует только написание кода за деньги
Это работает только в супермелких конторах, где все и всё на виду.

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

0>>Я не говорю, что фреймворки и платформы — это зло и их не надо разрабатывать в принципе.
A>У вас была одна проблема. Для её разработки вы решили сделать/использовать платформу/фреймворк — теперь у вас две проблемы

две обычно меньше чем одна большая

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

М>>ЗЫ. когда я начинал изучать JS, то первое что я стал писать -- это логгер. шеф покрутил пальцем и виска и показал на готовый, которым до сих пор пользуюсь.
0>Боюсь, есть недопонимание. Я ничего не имею против фреймворков в принципе, я имею кое-что против определённого ущербного мыслительного процесса, который приводит к появлению нежизнеспособных фреймворков.

Жизнеспособные фрэймворки могут появиться только как обобщённое решение уже когда-то решённых проблем. Если решать общую задачу вместо частной, то да, появится нежизнеспособный фрэймворк.

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

Ф>Жизнеспособные фрэймворки могут появиться только как обобщённое решение уже когда-то решённых проблем. Если решать общую задачу вместо частной, то да, появится нежизнеспособный фрэймворк.
Это понимание приходит с потом и кровью после наивных попыток сделать наоборот.

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

0>Вообщем, наброс сделан, жду ваших мнений

Фреймфорики и "общие шины" это попытка не только решить проблему заказчика, но и построить за его счет тиражируемое решение которое будет кормить программиста долгие годы. Фактически удочка vs рыба.

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

P>Фреймфорики и "общие шины" это попытка не только решить проблему заказчика, но и построить за его счет тиражируемое решение которое будет кормить программиста долгие годы. Фактически удочка vs рыба.
Я с этим полностью согласен. Другое дело, что в описываемых случаях за такую разработку берутся необоснованно. Зря тратят время и деньги, получают в итоге кучу сверхсложного легаси с огромной стоимостью владения.

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

0>Я с этим полностью согласен. Другое дело, что в описываемых случаях за такую разработку берутся необоснованно. Зря тратят время и деньги, получают в итоге кучу сверхсложного легаси с огромной стоимостью владения.

В смысле необоснованно? За разработку платит заказчик, а результат получают программисты. Это ли не счастье?

Здравствуйте, 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 понравившуюся функциональность.
Пример про скелет установщика сервиса — это было просто пример такого подхода, ес-но.
Но ты намек не понял.

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

V>И опять и снова — не о том аргументируешь.
О, очередной приступ некрофилии?
V>Это UI не надо рисовать ручками, поэтому его низкоуровневое представление абсолютно не принципиально.
Ну конечно же надо. Дефолтный UI устраивает чуть меньше, чем никого. А механизмов расширения — упс, нету.
S>>Во-первых, это новый стандарт, требующий разработки отдельного тула, который стоит денег.
V>Тул идёт в SDK.
Если уж захотелось откопать мёртвую тему, потрудитесь ознакомиться с предметом дискуссии. Речь идёт о принятии архитектурных решений — на момент проектирования WI никакого SDK и тула не было.
Зато был тул для рисования Dialog Templates. То есть неизвестный нам архитектор спустил в унитаз значительный объём корпоративных ресурсов — без малейшей к тому причины.
Просто потому, что ему так захотелось.
V>Любое расширение означает некий "левый" работающий код. Я уже указывал, что это будет дыра в безопасности.
От повторения чуши она не становится более умной. В любом инсталлере есть дофига "левого" работаюшего кода, и никого это не беспокоит. Чем код UI хуже, чем код custom actions?
А если мы уж допустили чужой код в одном месте, то какой смысл запрещать его в другом?
Тем более, что код гуя, в отличие от кода custom actions, работает под ограниченными привилегиями текущего пользователя, а не в контексте сервиса windows installer.
V>Забудь про рукописность UI.
C чего это вдруг? Глаза откройте — 99% инсталляторов используют рукописный UI. То есть мы имеем мега-дорогой, переусложнённый, неудобный инструмент, который ещё и не покрывает потребности целевой аудитории.
Это даёт нам просто канонический пример архитектурного факапа.
V>Бла-бла-бла.
V>MSI создавался для установки продуктов офиса.
О, у вас появилась новая идея, как оправдать идиотскую точку зрения "windows installer архитектурно оправдан".
Вообще-то — нет. WI позиционировался как штатный инструмент для установки чего угодно.
Да, многие сценарии в нём были навязаны офисной командой. Но office team не диктовала, как реализовать всё это внутри. Можно было принимать любые архитектурные решения, а не только идиотские.

V>Там полно сложных сценариев и они все покрыты. Если тебе надо указать конкретный инстанс SQL-сервака, то под это дело заводится "символ", т.е. переменная и указывается как параметр, либо, если не указана, то можно дернуть CustomAction для демонстрации юзверю любого диалога.
То есть это уже не дыра в безопасности?
V>Например, в нашей инсталляхе диалоги были вообще нейтивные, а не дотнетные. Диалогов было несколько и с нетривиальной логикой — вот как раз для указания настроек сервака приложения, с возможностью проверки этих настроек. А для сервака приложений в инсталляхе — указать адрес/инстанс SQL-сервака.
Дело не в указании адреса/инстанса, а в том, что ломается весь механизм проверки наличия предыдущих версий софта — потому что их может быть одновременно много.
V>Кароч, ВСЕ, ну т.е. вообще все приведённые тобой контр-примеры — это какой-то детский лепет, который у разработчика занимает не более рабочего дня.
Это просто вы, как обычно, выступаете на незнакомую вам тему.
V>Не видел бы, не давал советов. Я ведь увидел еще тогда, что все советы прошли мимо уха не задерживаясь. Такое ощущение, что или я плохо объясняю, или кого-то совершенно не интересует обсуждаемый предмет, а интересует исключительно подвергнуть MSI обструкции любыми способами. ))
Вы не понимаете сути. Речь не о том, что убогость MSI нельзя обойти — конечно можно! Ведь продукты-то ставятся! Я разработчик — я вообще любую разрешимую проблему могу решить.
Мы сейчас обсуждаем не применение WI на практике — тем более, что с этой темой вы очень поверхностно знакомы. Мы обсуждаем архитектуру этого продукта. И если бы разработчики WI думали головой, а не тем местом, которым они думали, то этих "легко разрешимых" проблем бы не было вообще. Конечно, если убогая технология не позволяет мне подменять один контрол — то я перерисую весь диалог. Ну, будет это в 10 раз дороже — так я ж не бесплатно это делаю, зарплату получаю.
Ок, диалог плохо сочетается с остальными шагами визарда — давайте весь визард заменим на кастомный код. Ещё впятеро дороже получилось — но чего уж там, деньги-то не мои.

Вы посмотрите на это со стороны производителя — выброшены мега-деньги; кто-то сидел, ночей не спал, придумывая структуру табличек с контролами. Кто-то писал тул. QA гоняло всю эту чушь туда-сюда. Документация писалась и переводилась на разные языки. А на практике — нихрена это никому не помогает: всё уехало в помойку. Все, даже признанные знатоки MSI типа vdimas, пишут нативные диалоги вместо реляционного убожества.

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

V>Это много говорит о твоей внимательности. Я же предлагал уже решение для твоих проблем с установкой сервиса (у нас была такая же задача) — создаешь проект-заглушку в дотнете с установкой сервиса и перегоняешь полученный пакет в WiX. И вот как раз один из типовых кусков таким образом и нарисовался.
Речь не о моих проблемах. Я все свои проблемы с инсталляторами решил ещё до 2010 года. Речь о причинах, по которым эти проблемы возникли. В нормально спроектированной системе таких проблем быть не должно вообще, от слова совсем.
V>И?
И напороли такой чуши, что я работать не мог от смеха.
V>Зачем msiexec.exe? АПИ инсталлера полон, ты можешь сам написать утилиту-аналог msiexec.exe за пару вечеров под основные сценарии. Причем, эту утилиту можно написать на каком-нить скриптовом VBS.

Вы дома посмотрите, какой процесс у вас кушает CPU в процессе исполнения вызовов этого API.

V>Пока что выяснилось, что ты за деревьями не увидел леса. Выбрав в кач-ве основного фокуса приложения усилий WiX, ты не потратил должного времени на изучение структуры таблиц инсталляхи, на изучение COM-АПИ инсталлера, на понимание правил многократного разыменования референсов.
V>Кароч, ты начал не оттуда. К стадии WiX надо было подходить только освоив все предыдущие стадии. Горе тому, кто пытается пользоваться инструментом под некую предметную область, не понимая самой предметной области. Обезъяна с гранатой, как грится.
Опять мимо. WiX — это было последнее, к чему мы пришли. Наевшись и стандартного тулчейна, и купленного InstallShield, и ручного разбора с Orca, и всего остального.

V>Во-во. Нубство как оно есть.

V>Компонентом может быть что угодно, например, запись в реестре или параметр, который достаётся через кастомную акцию.
Садитесь, два.
V>Кароч, курить, что есть "компонент".
"Что угодно", my ass. Ну, покажите мне, как описать компонент, который имеет версию, определяемую через custom action, и никак не отражён в файловой системе. Что будем писать в KeyPath?

V>Версии надо присваивать продуктам, а не компонентам. Ну и все танцы вокруг т.н. "кода обновления" или уникального нового кода, чтобы разные версии жили одновременно, не мешая друг другу.
Это кто вам такое сказал?
S>>Вы почитайте немножко вот здесь: http://msdn.microsoft.com/en-us/library/aa368070(v=vs.85).aspx
V>Это не ответ. Тем более это не ответ от тебя, т.к. если ты ручками MSI АПИ не дергал, то не тебе отсылать к доке по нему. ))
Это не MSI API. Там про API ничего нету. Там рассказано, как писать custom action.

V>Я же описал, как получить "скелет" для грамотно описанной custom actions. Понятное дело, что породить подобный скелет с 0-ля ручками — это застрелиться. А зачем ты так делаешь?
Нет, ничего про скелет custom action написано не было. Кроме упоминания про многократное разыменование — это, надо полагать, единственное, что вы делали реально в инсталлере.

V>Я как раз предлагал сваять скелет на MSI и перегнать его в WiX, вычленив необходимое.
Вы путаете custom action со структурой пакета. "А строил из себя спеца." (TM)
Чтобы вы примерно поняли, о чём речь: допустим, один из компонентов вашего продукта — это служебный SSL сертификат, который ставится на backend-сайт. Ваша задача — описать custom action, который его поставит, если его не было, заменит, если он был, но старый, и не будет трогать, если он уже заменён на более новый. Под "ставится" мы подразумеваем регистрацию в IIS и активацию для соединений по порту 8443. При деинсталляции фичи, в которую входит этот компонент, нужно его снести. Какие шаги вы предпримете для написания custom action? Где вы возьмёте "скелет"?

Ещё раз: мы обсуждаем не мою личность, как разработчика инсталляторов. Мы обсуждаем клиническую убогость архитектуры Windows Installer, которая создаёт в разы больше проблем, чем решает.
То, что другие разработчики смогли потратить человекогоды для того, чтобы заполнить некоторые дыры этой архитектуры, хорошо для нас, как прикладников. Но плохо для тех, кто всё это придумывал с самого начала.

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

S>Если уж захотелось откопать мёртвую тему, потрудитесь ознакомиться с предметом дискуссии.

Недержание?


S>Речь идёт о принятии архитектурных решений — на момент проектирования WI никакого SDK и тула не было.

MSI SDK шел изначально с MSI и уж тем более на дату начала этого обсуждения уже давно как был.
Остальные заламывания рук скипнул.

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

V>>MSI создавался для установки продуктов офиса.
S>О, у вас появилась новая идея, как оправдать идиотскую точку зрения "windows installer архитектурно оправдан".
S>Вообще-то — нет. WI позиционировался как штатный инструмент для установки чего угодно.
S>Да, многие сценарии в нём были навязаны офисной командой.

Для особо упоротых — этот продукт под офис и разрабатывался. А потом стал позиционироваться "для всего".

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

По-сути, ты предлагаешь ограничить возможность разработки кастомных контролов. Т.е. надо было дать некую UI-библиотеку сугубо для инсталлера. А если у меня есть свои контролы (в дотнете, нейтиве, в другой какой-нить технологии — не важно), то, вместо их повторного использования в кастомных своих диалогах/визардах, я должен буду портировать их реализацию на вот эту прибитую к MSI гвоздями технологию. И кто-то тут еще рассуждает о "грамотном дизайне"...

Кароч, пару лет прошло, а ты до сих пор за деревьями леса не видишь. WI — это, в первую очередь, движок.
Ты можешь вообще всё ГУИ инсталлера нарисовать самому и пользоваться MSI API сугубо для того, чтобы дергать ф-ии этого АПИ.


S>Дело не в указании адреса/инстанса, а в том, что ломается весь механизм проверки наличия предыдущих версий софта — потому что их может быть одновременно много.

Т.е. ты НИ РАЗУ не передавал как параметр своим custom actions инстанс текущей инсталляхи и НИ РАЗУ не дергал MSI API из своих кастомных акций?
Какой ужас... ))
А как ты вообще эти кастомные действия пишешь? Что ты в них можешь полезного сделать без инстанса текущей инсталляхи?

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

V>MSI SDK шел изначально с MSI и уж тем более на дату начала этого обсуждения уже давно как был.
ОМГ, вы совсем неспособны понять предмет дискуссии?
Мы говорим не о времени начала дискуссии. А о моменте, когда Installer Team была сформирована и ей была поставлена задача разработать архитектуру Windows Installer.
Я думаю, что это эпохальное событие произошло когда-то в девяностых.

Здравствуйте, vdimas, Вы писали:
V>Для особо упоротых — этот продукт под офис и разрабатывался. А потом стал позиционироваться "для всего".
У вас есть какое-то подтверждение этой забавной теории?

V>По-сути, ты предлагаешь ограничить возможность разработки кастомных контролов. Т.е. надо было дать некую UI-библиотеку сугубо для инсталлера.
Нет. Надо было
1. Обеспечить совместимость с Dialog Templates для максимизации использования тулчейна
2. Обеспечить возможность subclassing и superclassing так же, как в стандартных диалогах — чтобы объём работы зависел от количества нестандартных требований линейно, а не скачкообразно.

Ваши предложения по возможной архитектуре UI в Windows Installer я поскипал — там нечего комментировать.

V>Ты можешь вообще всё ГУИ инсталлера нарисовать самому и пользоваться MSI API сугубо для того, чтобы дергать ф-ии этого АПИ.
При чём здесь MSI API? Я вам о том, что вся структура пакета — бред наркомана.
V>Т.е. ты НИ РАЗУ не передавал как параметр своим custom actions инстанс текущей инсталляхи
Что вы называете "инстанс текущей инсталляхи"? hInstall ? Это совсем не то же самое, что инстанс SQL Server. Просто называется похоже.
Впрочем, от человека, который путает Skype со Skype for Business, я иного и не ожидал.

V>А как ты вообще эти кастомные действия пишешь? Что ты в них можешь полезного сделать без инстанса текущей инсталляхи?
Я так понимаю, что за вот этими модными словами скрывается банальный вызов MsiGetProperty()?
Потому что другого способа передать инфу в custom action и нету.

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

P>В смысле необоснованно? За разработку платит заказчик, а результат получают программисты. Это ли не счастье?
Что-то программисты там особо счастливыми не выглядели...

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

V>>MSI SDK шел изначально с MSI и уж тем более на дату начала этого обсуждения уже давно как был.
S>ОМГ, вы совсем неспособны понять предмет дискуссии?

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


S>Мы говорим не о времени начала дискуссии. А о моменте, когда Installer Team была сформирована и ей была поставлена задача разработать архитектуру Windows Installer.
S>Я думаю, что это эпохальное событие произошло когда-то в девяностых.

Это эпохальное событие произошло одновременно с выпуском MS Office 2000, когда в папке с пререквизитами к нему впервые засветился WI и его надо было самому ручками устанавливать перед установкой офиса.

Здравствуйте, 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 с обычного скайпа. Сюрпрайз? Не знал?

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

А вообще, ты странный тип на этом сайте.
Вроде бы порой говоришь весьма умные вещи. Но чаще даёшь понять, что ты, всё-таки, нифига не программист и никогда им всерьёз не был.
Ну типа как вот эти твои комменты:

Ну, покажите мне, как описать компонент, который имеет версию, определяемую через 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", по которому далее ветвиться в других шагах инсталляции.