Сколько из вас использует разработчик, разработанный внутри вашей компании?

Question

Некоторое время назад возникла дискуссия о том, следует ли нам использовать сторонний установщик или написать свой собственный. У нас было 2 поколения внутренне разработанных инсталляторов, которые просто выполняют сервисы, сценарии msmq, com +, gac и sql, передавая их в exe.

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

Спасибо

Answer 1

Мы используем пользовательский здесь. У нас было много странных вещей, которые нам нужно было сделать, в том числе создание соединений , редактирование разделов реестра других пользователей (что требует поиска и загрузки их ульев), регистрация материалов с помощью нашего стороннего слоя HAL в реальном времени, и т. д. Теперь могут существовать наборы инструментов для установки, которые позволяют вам делать все это, но их будет сложнее освоить, чем просто делать это самим.

Я думаю, что у нас все C ++.

Answer 2

В прошлый раз, когда я писал собственный установщик, он был где-то в 1992 году под Windows 3.0. Я сделал это только тогда, потому что был молод и наивен. Я не могу понять, почему кто-то будет беспокоиться в эти дни.

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

Был проект, который у меня был пару лет назад, когда установщик должен был поиграть с некоторыми сетевыми настройками на локальном ПК, поэтому я написал простой маленький EXE-файл, чтобы сделать этот бит, и получил InstallShield для его запуска часть установки. Это отлично работало и было намного проще, чем писать полный установщик.

Answer 3

Symantec разработала собственный установщик Norton AntiVirus 2009. Он вообще не использует установщик Windows (msiexec.exe).

Таким образом они сокращают общее время установки до менее чем 1 минуты.

Answer 4

У нас есть наш собственный установочный пакет, и его выполнение не является частью моего списка «Что не делать ...»

Хотя я согласен с тем, что многие установщики имеют очень ограниченные наборы функций и некоторые (криплинг) возможности, другие предлагают большую гибкость. Это говорит о том, что я еще не начал искать альтернативы, но это будет то, что я буду делать в наступающем году. Мне нужно что-то, в чем я могу:

1. Создание моих собственных модулей, плагинов или любой другой поддерживаемой модели расширения на реальном языке программирования (java, .NET ... что угодно, если поддерживаемый язык инструмента установщика начинается с названия компании с именем инструмент это ОСНОВНОЕ отключение)
2. Поддерживает все основные версии Windows.
3. Поддерживает Linux
4. Поддерживает автоматическую установку

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

Я предпочитаю поддерживать несколько специализированных инструментов и плагинов, чем полную систему для многоплатформенного развертывания.

ИМХО создание собственного чего-либо должно быть последним вариантом.

Answer 5

Однажды (около 2002 г.) я вручную написал крошечный установщик (<200 КБ), который проанализировал версию Windows пользователя и затем загрузил соответствующий «основной» установщик для приложения. Похоже, в наши дни этот подход широко используется:) </p>

Кроме этого, в большинстве случаев, когда мне приходилось разрабатывать установщик для программы, это делалось с помощью InstallShield, WISE, InstallAware или другой альтернативы (например, WiX).

Реальность такова, что стоимость обслуживания и поддержки специального установщика может быть довольно высокой, особенно с каждой выпущенной новой ОС, и большая часть этой стоимости может быть компенсирована покупкой или инвестированием в один из этих коммерческих продуктов (или альтернатив). .

Сказав это, многие установщики могут быть довольно тупыми. Один конкретный продукт требовал использования InstallShield Pro - просто чтобы мы могли записывать собственные действия в InstallScript!

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

Да, и убедитесь, что вы учитываете исправления сценариев, обновлений, установок с правами администратора или без них, (если применимо) автоматической установки, многоязыковой поддержки в пользовательском интерфейсе ... и т. Д. Это может стать очень грязным, очень быстро.

Answer 6

Я привык на своей предыдущей работе.

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

Если вы можете, это был своего рода развертыватель clickonce, но поддерживающий сразу несколько версий вместо одной.