> Потому что нечего пихать в инсталляторы всякую дрянь.

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

И вот ты мне тут пишешь, что я пихаю в инсталятор всякую дрянь.

Ладно, вдруг ты умный челоек, начинаю самокопаться. Ищу в чем я не прав.
Начинаю соображать, какой САМЫЙ КРУТОЙ МС ИНСТАЛЯТОР на который можно было бы ориентироваться как на идеал.
Инсталятор Visual Studio(!). Типо идеал. Но лучше его лишний раз не запускать
Потом впоминаю, что на моей машине так и не установлен сервиспак на студию, потом вспоминаю как я его устанавливал, с переустановками, с редактированием реестра вручную, с докачкой компонент с сайта МС, с переустановками инсталятора студии, как он потом слетал когда устанавливал отдельные дополнительные компоненты, как он так и не устанавливался, хотя шуршал собака и не давал работать хрен знает сколько времени (транзакция же еп!), и с откатами, тоже ведь шушит полчаса откатываясь почти с конца процесса установки.
Ну еп, идеал.
Еще вспомнил. На Вынь 7 сервиспак студии тоже не устанавливается сразу. Им пришлось специально патчить процесс. Он если с нескольких попыток не установился штатно, то потом как-то чудесно вдруг устанавливается при абсолютно тех же условиях и в том же окружении. Хотя это может и не везде так.

Представил такое счастье я буду продавать рядовому пользователю
Короче, грызите кактусы дальше, с меня хватит.

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

>> Потому что нечего пихать в инсталляторы всякую дрянь.

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

G>И вот ты мне тут пишешь, что я пихаю в инсталятор всякую дрянь.

Я не имел в виду тебя лично. Если ты меня не так понял — извини.
У нас система установки продукта тоже проектируется таким образом, чтобы быть максимально
примитивной, быстрой, не зависеть от версии Windows, сервис-пака, языка системы и прочих факторов.
Чтобы устанавливаться в стиле "next->next->next" за несколько секунд. И это работает.
Работает не в последнюю очередь потому, что из сценария установки было выброшено все лишнее,
что могло стать источником проблем на всяких редких конфигурациях.

< ... здесь описываются ужасы работы инсталлятора Visual Studio ... >

G>Представил такое счастье я буду продавать рядовому пользователю

Возможно, установщик сервис-пака и глючный. Хотя у меня, к примеру, установился без проблем.
А инсталлятор самой "Студии" ? Ее же скачивает и устанавливает огромное количество народа
ежедневно — если бы проблема имела бы место, об этом бы трубили на пол-интернета.
Но такого, за определенным процентом исключений, не наблюдается.

Давай попробуем найти эквивалентный по сложности установки продукт, написанный не на
технологии MSI/WIX, который был бы свободен от ошибок. Я таких не знаю, если что.

> Давай попробуем найти эквивалентный по сложности установки продукт, написанный не на
> технологии MSI/WIX, который был бы свободен от ошибок. Я таких не знаю, если что.

Вот ты меня опять зовешь — "Идем, там полянка таких сочных и свежих кактусов". "Лучше день потерять, потом за пять минут долететь". Не хочу. Не могу. Моя задача уже решена.
Посмотри примеры сложных опен-сорсных пакетных инсталлеров. Или NetBeans тот же. Люди как-то развиваются, а не стоят по 20 лет на месте.

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

>> Давай попробуем найти эквивалентный по сложности установки продукт, написанный не на
>> технологии MSI/WIX, который был бы свободен от ошибок. Я таких не знаю, если что.

G>Вот ты меня опять зовешь — "Идем, там полянка таких сочных и свежих кактусов". "Лучше день потерять, потом за пять минут долететь".

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

G>Не хочу. Не могу. Моя задача уже решена.

Нет проблем.

G>Посмотри примеры сложных опен-сорсных пакетных инсталлеров. Или NetBeans тот же. Люди как-то развиваются, а не стоят по 20 лет на месте.

Мне хватило Cygwin.

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

На это я согласен. Только без агитаций в стиле "нечего пихать в инсталляторы всякую дрянь" пожалуйста

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

>> Самодельный.
W>За нафига?

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

SMARTInstall(const sShortProjectName, sLongProjectName, sPublisher: String; AutoRun: Boolean; NeedAdministrativePrivileges: Boolean);

Пример программы с этим инcталлятором — "Звуковой детектор"

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

O>Не ради флейма — о чем конкретно речь ?
O>Можешь привести пример проблем, связанных с этими privileges, storage management ?

Да банально: операции, которые совершает MSI требуют админских привилегий, но при этом у сервиса MSIExec, из под которого этот MSI в итоге выполняется, попросту нет необходимой привилегии (не disabled а вовсе отсутствует), требуемой для работы со storage, из-за этого невозможны жизненно необходимые операции c дисками и volumes.
+ из DLL custom actions были проблемы с MS Cluster API. Из exe — работало. Так что custom actions приходилось делать Exeшниками, но там интероп с MSIExec практически никакой, т.е. custom action повлиять на ход дальнейшего процесса кроме как Abort + Rollback никак не мог.
+ нюансы установки и удаления storport дров в W2008R2, учитывать которые из MSI очень геморно и error prone.
+ нюансы поведения самого MSI. К примеру в разных режимах (quiet, unattended, и т.п.) некоторые actions могли отработать в разной последовательности: типа внезапно проверка проперти начинала происходить до её присвоения.
+ сложности с созданием conditional rollback.
+ сложности с rolling upgrade.
+ сложности с контролируемым частичным uninstall, необходимым для repair/upgrade.

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

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

G>Мне помогает. В том смысле, что моя уверенность в полной негодности технологии MSI и всяких Wix-ов подтверждается.
Ну, она годная, но для простых вещей. Как только начинается хоть что то реально нестандартное сразу начинается разного рода геморрой.
Мы дожили до версии 1.3 нашего продукта, с каждой minor версией сталкиваясь с новыми "нюансами работы". После 1.3 объём работы, затрачиваемый на обходные манёвры оказался в разы больше чем затрачиваемый на полезный функционал setup.

G> Проще и удобнее прописать все своим кодом, чем рисовать xml-ки или редактировать таблички.
Для нас это оказалось на порядки проще. Мы потеряли в уникальных фичах MSI типа автоматической удалённой установки на машинах в домене, но приобрели неограниченную гибкость процесса установки, и наконец то перестали тратить время на "обвязку шоп заработало".

G>Сам я опасался принять для себя такое решение, перейти с мейнстримовых технологий МС на что-то альтернативное.
Ну с поставить/удалить у нас и WIX сносно справлялся. Львиная доля проблем была с upgrade.

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

O>Потому что нечего пихать в инсталляторы всякую дрянь.
Upgrade это дрянь?

O>Инсталлятор для того нужен, чтобы скопировать на компьютер пользователя нужные файлы,
O>зарегистрировать в системе компоненты, создать ярлыки, службы.
А затем это всё обновить, да так, чтоб ничего не сломалось и остальные компоненты системы продолжали нормально работать, в том числе и на других нодах.

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

O>У нас система установки продукта тоже проектируется таким образом, чтобы быть максимально
O>примитивной, быстрой, не зависеть от версии Windows, сервис-пака, языка системы и прочих факторов.
O>Чтобы устанавливаться в стиле "next->next->next" за несколько секунд. И это работает.

Install/Uninstall — это так, баловство.
Не забудь, что потом надо ещё и обновиться на новую версию. Желательно тоже next->next->next
При этом у нас уже полные storage юзерских данных, просрать которые будет очень больно. Ну и если во время апгрейда что нить сломается будет тоже сильно неприятно.