Здравствуйте, 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 и нету.