Comments 19
Сегодня день защиты Adobe :)
А зачем вообще нужны инсталляторы? Чтобы скрывать от пользователя всякие файлы, в которых учитывается время триала коварными разработчиками и сделать ещё более не понятный процесс инсталляциии копирования файлов?
Не проще ли просто извлечь файлы из архива? Или они так боятся, что все их творения будут разграблены безжалостными и беспощадными пиратами? Да и как показала недавняя ситуация с самизнаетекакой игрой. Врят-ли инсталлятор тут сильно поможет.
Добавление конфигуразционных данных в реестр? Тоже как-то под большим вопросом, зачем?
Не проще ли просто извлечь файлы из архива? Или они так боятся, что все их творения будут разграблены безжалостными и беспощадными пиратами? Да и как показала недавняя ситуация с самизнаетекакой игрой. Врят-ли инсталлятор тут сильно поможет.
Добавление конфигуразционных данных в реестр? Тоже как-то под большим вопросом, зачем?
Например, если у нас продукт основанный на Java, то для его запуска требуется JRE определенной версии. Инсталлятор может выбрать необходимую для запуска.
С помощью инсталлятора можно выбрать необходимы для установки фичи, избежать конфликтов внутри них.
Обновление или переконфигурирвание программы.
Вообще список можно продолжить.
С помощью инсталлятора можно выбрать необходимы для установки фичи, избежать конфликтов внутри них.
Обновление или переконфигурирвание программы.
Вообще список можно продолжить.
А почему бы об этом не написать в readme? Это раз.
Во вторых, как быть, если конфликт не в вериях и зависимостях от JRE, а например от программ других разработчиков? Хотя пожалуй bobermaniac в комментарии чуть ниже меня убедил, но всё же, как-то это всё мутно…
Для этого можно использовать какой-нибуть скрипт, который можно рекомендовать запускать после установки.
Да, кстати, забыл упомянуть, всё, что я назавл имел ввиду для малых программ различных утилит, браузеров, и тому подобных, естественно, что для какого-нибудь крупного проекта написанного на Java и требующего JRE и прочие необходимые для работы сложные вещи, без инсталлятора будет довольно сложно, но возможно! ;-J
К тому же практика установки, как бы существует. И весьма даже юзабильно ))
Ну и к тому же, тут мы получаем такую ситуацию, что у каждого производителя свой собственный инсталлятор, с блэкджеком, ну и вы поняли… которыйсрплевать хотел на зависимости и конфликты других приложений.
Ещё раз повторюсь, если ставится большой пакет на машуину которая будет выполнять определюённые задачи, то инсталлятор лучший выблор.
А как быть, если на машине много разных приложений, много инсталляторов, много версий, много разных баз данных о приложениях, и огромная помойка файлов?
Вместо минусов, объясните, как это разруливается!
Во вторых, как быть, если конфликт не в вериях и зависимостях от JRE, а например от программ других разработчиков? Хотя пожалуй bobermaniac в комментарии чуть ниже меня убедил, но всё же, как-то это всё мутно…
Для этого можно использовать какой-нибуть скрипт, который можно рекомендовать запускать после установки.
Да, кстати, забыл упомянуть, всё, что я назавл имел ввиду для малых программ различных утилит, браузеров, и тому подобных, естественно, что для какого-нибудь крупного проекта написанного на Java и требующего JRE и прочие необходимые для работы сложные вещи, без инсталлятора будет довольно сложно, но возможно! ;-J
К тому же практика установки, как бы существует. И весьма даже юзабильно ))
Ну и к тому же, тут мы получаем такую ситуацию, что у каждого производителя свой собственный инсталлятор, с блэкджеком, ну и вы поняли… который
Ещё раз повторюсь, если ставится большой пакет на машуину которая будет выполнять определюённые задачи, то инсталлятор лучший выблор.
А как быть, если на машине много разных приложений, много инсталляторов, много версий, много разных баз данных о приложениях, и огромная помойка файлов?
Вместо минусов, объясните, как это разруливается!
Согласен, в любой инсталлятор можно встроить что угодно, как и в любую программу.
Вы страшный человек.
Возможности инсталляции методом xcopy кончились еще во времена DOS. Сейчас это применяется только для простых проектов.
Настоящий инсталлятор должен:
1. Проверить окружение (версии системы, фреймворков) и запустить инсталляцию нужных версий, если это необходимо
2. Скопировать файлы
3. Установить права
4. Зарегистрировать компоненты
5. Запустить сервисы
6. Зарегистрировать типы
7. Создать сценарий деинсталляции
Это минимум для среднего приложения.
В случае например с приложением ASP.NET — все еще хуже, там надо добавить приложение в пул IIS и настроить его.
Возможности инсталляции методом xcopy кончились еще во времена DOS. Сейчас это применяется только для простых проектов.
Настоящий инсталлятор должен:
1. Проверить окружение (версии системы, фреймворков) и запустить инсталляцию нужных версий, если это необходимо
2. Скопировать файлы
3. Установить права
4. Зарегистрировать компоненты
5. Запустить сервисы
6. Зарегистрировать типы
7. Создать сценарий деинсталляции
Это минимум для среднего приложения.
В случае например с приложением ASP.NET — все еще хуже, там надо добавить приложение в пул IIS и настроить его.
В конкретном случае, пожалуй да, тут я с Вами соглашусь, это удобно, когда программа настраивается скриптом, который знает что нужно.
Но как быть если зависимостей много, и многие из них неизвестны? А если «Враждебная программа» использует инсталлятор другой фирмы, базы инсталляторов разные? Ну и чтобы дважды не описывать, прочтите мой предыдущий комментарий чуть чуть выше.
Но как быть если зависимостей много, и многие из них неизвестны? А если «Враждебная программа» использует инсталлятор другой фирмы, базы инсталляторов разные? Ну и чтобы дважды не описывать, прочтите мой предыдущий комментарий чуть чуть выше.
А теперь объясните сферической секретарше в вакууме, почему вместо запуска одного файлика банк-клиент-инсталл.msi
Она должна скачать и поставить JRE версии, указанной в readme, прописать переменные окружения, создать bat'ник и вывести ярлык на рабочий стол???
Она должна скачать и поставить JRE версии, указанной в readme, прописать переменные окружения, создать bat'ник и вывести ярлык на рабочий стол???
Вот в LFS никаких проблем с инсталляторами:
./configure
make
make install
./configure
make
make install
WiX бесплатный. Open Source. Баги можно чинить самому, можно заводить в их бегтрекере. Заводил, мелкие чинят в течении 1-2 месяцев, серьезных не видел. Если самому засабмитить патч — то в течении нескольких дней.
Вообщем-то единственное преимущество InstallShield относительно Wix — строенные качественне локализации на 50+ языков. В WiX локализаций моменьше и нет никаких гарантий что они хорошо написаны :).
Сам использую InstallShield и WiX. С последним проблемм вообще не было. Если бы не было требования у компании по поводу локализаций — только его бы и использовал.
Вообщем-то единственное преимущество InstallShield относительно Wix — строенные качественне локализации на 50+ языков. В WiX локализаций моменьше и нет никаких гарантий что они хорошо написаны :).
Сам использую InstallShield и WiX. С последним проблемм вообще не было. Если бы не было требования у компании по поводу локализаций — только его бы и использовал.
Спасибо, обязательно посмотрю WiX. Локализация не такая уж большая проблема, ее можно заказать, но встречаются коммерческие проекты, в которых запрещено использовать Open Source :(
Там есть больше 30 локализаций, заказывать придется экзотические вроде малазийского. Те что есть надо… как бы так сказать… проверять на ком-нить :).
Непосредственно Open Source запрещают редко. Обычно волнуются по поводу лицензионной чистоты. Но тут какбэ проблем нет, потому что во-первых проект от Microsoft, во-вторых он сам по себе только создает MSI — его кода внутри созданного MSI нету.
Непосредственно Open Source запрещают редко. Обычно волнуются по поводу лицензионной чистоты. Но тут какбэ проблем нет, потому что во-первых проект от Microsoft, во-вторых он сам по себе только создает MSI — его кода внутри созданного MSI нету.
Sign up to leave a comment.
Баги в инсталляторах. А где их нет?