Здравствуйте, 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 корректно работать. Вместо того, чтобы просто написать логику инсталляции на каком-нибудь приемлемом языке программирования.