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

V>Да че за бред-то???
V>Есть некий АПИ инсталлера, а есть к нему "движок", в котором можно закодировать вызовы этого АПИ декларативным способом. Классика декларативного подхода — описание зависимостей. Всё.
Я вот когда-то писал визуальную обёртку на Дельфи для MSI, которая позволяла делать простые инсталляторы. Ну то есть, чтобы тупо скопировать файлы, создать иконки на рабочем столе и, возможно, файловые ассоциации.

Это был АДЪ.

Через пару лет я ещё пытался сделать инсталлятор для промышленной утиллиты, которая ставила драйвера и в которой нужно было на этапе установки проверить наличие и лицензированность железки. Ну и там были мелочи типа зависимости от Embedded MSSQL (или как он там называется).

Это был АДЪ^3.

V>Ну и изначально расчет был на высокоуровневый инструментарий и этого инструментария хватает, удобного. Другое дело, что он платный. Дык, это другая тема уже.
Нету вообще никакого нормального инструментария, хотя за стоштукобаксов. СОВСЕМ.

При том, что на вражеских платформах типа Линукса это же делается без особых проблем.

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

V>Мдее...
V>Опиши в MSI только продукты и компоненты. Не возись с файлами, зависимостями и прочей "наркоманией", если не хочешь.
V>Перехвати требуемые custom actions и пусть в них работают твои bat-скрипты.

И для чего тогда этот инсталер ?

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

V>>Опиши в MSI только продукты и компоненты. Не возись с файлами, зависимостями и прочей "наркоманией", если не хочешь.
V>>Перехвати требуемые custom actions и пусть в них работают твои bat-скрипты.

I>И для чего тогда этот инсталер ?

Чтобы эти скрипты руками не писать, вестимо.
Накидал мышкой в каком-нить визуальном редакторе пакета, проставил галочки — и всё отлично работает.

Ну и более подробно отвечал уже — на нем высокоуровневая логика, учет зависимостей продуктов -> компонентов, типовые сценарии и т.д.

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

S>Это всё здорово, если бы в нагрузку не шла реляционная база данных.



Ну, право, это как критиковать сегодня морально устаревший набор кодов Интел-совместимых процессоров, со всеми их расширениями SSEx, где итоговая бинарная кодировка одна из САМЫХ НЕОПТИМАЛЬНЫХ В ИНДУСТРИИ! И чё??? Да ничё. Все понимают, никто и не спорит, но это никого не парит.


V>>Еще раз для особо одаренных. Изначально был расчет на коммерческие приложения, где это, действительно, несложно.
S>Ещё раз для особо одарённых: это несложно для того сценария, в котором база данных не нужна вообще, от слова совсем.

Ну, вообще-то, в той информации достоверно прослеживаются уникальные ключи и связи. Таки стоит взглянуть на схему базы — она относительно несложная. Т.е. реляции предоставляются предметной областью, поэтому огульно высмеять её не получится никак, увы. Можно лишь поспорить относительно отдельных таблиц и связей. Я соглашусь только с иронией по поводу представления UI, но блин, в сотый раз оговорюсь, что эта ирония бессмыслена изначально, бо с выходом самой первой версии инсталлера в его SDK был тул по визуальному редактированию и тестированию UI. Более того, диалоги из разных пакетов можно склеивать в один целевой, то бишь некая контора вполне может хранить однажды разработанные диалоги в кач-ве библиотек.

Аналогично языка представления зависимостей. Он полон в декларативном смысле в терминах ВСЕХ объектов, описываемых базой инсталлера. Поэтому, да, некие вещи, выходящие за рамки информации, оперируемой инсталлерами, в нем описать нереально. Но это и хорошо — иначе бы это была дыра в безопасности.

Кароч, извините за самоповтор, но вся эта критика пока на уровне критики объектных кодов Интел-совместимых процессоров.

V>>Он фигню написал, ваще-то. Это как призывы писать программы на ассемблере. ))
S>Фигню пока что пишете исключительно вы. Вы сами-то хоть раз installshield запускали?
S>Там все эти install condition-ы пишутся точно так же, как в Orca — только не надо наизусть названия табличек знать. Вы попробуйте написать инсталлятор для веб-приложения, которое может ставиться в нескольких экземплярах на одном сервере, требует в зависимостях определённых фич IIS и наличия SQL Server Reporting Services, в который деплоятся (или апгрейдятся) репорты.
S>Я вас уверяю — коробку с InstallShield вы отнесёте на помоечку, и поставите себе WiX.

Мы используем Wise для чего-то уникального и только для совсем типовых пакетов — WiX, так что ничего сказать не могу. Последний раз, когда я пользовался InstallShield в 2003-м, он полностью удовлетворял всем моим нуждам.

S>И будете изучать структуру MSI, а вашим лучшим другом станет Orca.

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

V>>Опиши в MSI только продукты и компоненты. Не возись с файлами, зависимостями и прочей "наркоманией", если не хочешь.
V>>Перехвати требуемые custom actions и пусть в них работают твои bat-скрипты.
S>Круто. Вот это как раз и есть требование писать на асемблере. То есть все эти чудо-таблицы, получается, не нужны. Весь GUI делается в custom action на привычном нам языке, да? Все реальные действия по деплойменту компонентов делаются в custom action, да? Прекрасное подтверждение моего же тезиса.

Нет, это ты спросил, как обойтись без ВСЕЙ "наркоманской" базы, я тебе подсказал. Тебе достаточно использовать ту её часть, где реляционное представление как нельзя к месту. Ну вот подыграл твоему "чувству прекрасного", не более того.


S>Сразу видно человека, который custom action никогда в жизни не писал.

Сразу видно человека с проблемной самооценкой.


V>>Если у кого-то проблемы с руками и custom actions... блин, пусть создадут пустое приложение Windows Service на дотнете в студии, добавят к нему инсталлер сервиса, потом сделают пакет с ним и разберут получившийся MSI каким-нить просмотрщиком или экспортером в WiX. Это порядка 5-10 мин всех делов.
S> В отличие от вас, коллега, я (и, судя по всему, коллега Нахлобуч) провели немало часов "разбирая получившийся MSI" от разных инсталлер-генераторов. И от студийного, и от инсталлшилдовского, и от викса.

Ну тогда опять и снова для особо одарённых — я подсказал простой способ получения достоверно работающего результата на имеющемся почти у всех девелоперов инструментарии. Это был ответ на "ай-ай, проблемы с custom actions". )))

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


V>>Там не одна логика, а целый букет:
V>>- инсталляция
V>>- реинсталляция/восстановление
V>>- инсталляция по-требованию
V>>- деинсталляция
V>>- добавить компонент
V>>- убрать компонент
V>>- собрать инфо о пользователе
V>>- ...
S>Дупа в том, что встроенные действия, которые поддерживают всё вот это, крайне ограничены. А кастомные писать — геморрой. Как раз потому, что про них авторы мегаархитектуры думали меньше всего.

Можно подробнее — в чем именно геморрой?
Основной геммор как по мне — это в довольно большом кол-ве пропертей (некоторые из которых необходимо "разыменовать" как указатели, иногда более одного раза), но ими НЕОБХОДИМО оперировать, если пишешь вменяемый custom action. Дык, это как бы часть предметной области, не? Например, писал пакеты под RPM — там тоже дохренищща подобной предметной области. Се ля ви. И тут уже реляционность или объектность базы до одного места. ИМХО, наоборот, в реляционной базе доставать/разыменовывать пропертя удобнее, бо однотипнее, автоматизируется несложной однажды написанной либой.

V>>"Просто описать логику" можно лишь по каждой отдельной строчке. Дык, опиши! Твоя задача будет лишь дать имя/ключ продукту/компонентам и назначить всю ту "простую логику инсталляции" по соотв событиям. А если ты потратил хотя бы день-два на эту тему, то в твоём "просто описании" будет ветвление по пропертям, например, учет того факта: UI-инсталляция или silent, а так же уровень этого UI, административная инсталляция или локальная, на текущего юзера или на всех и т.д. и т.п.
S>В моём "просто описании" будет ветвление по тем пропертям, которые мне нужны. Если оно вообще нужно.
S>И в моём "просто описании" не будет этого колоссального разрыва между встроенной и продукто-специфичной логикой.
S>Собственно, WiX и есть попытка сделать DSL для платформы с идиотским дизайном. А то, что вы его не понимаете, показывает только то, что вы в жизни не сталкивались с разработкой инсталляторов для более-менее массовых продуктов.

Я понимаю для чего нужен WiX, но вижу непонимание у тебя. Этот DSL всё еще низкоуровневый, он плохо маскирует низлежащую платформу, поэтому пользоваться им напрямую для чего-то повторяемого — глупо. У нас, например, WiX генерится с помощью своих скриптов для однотипных пакетов. Дарю идею, как грится. )))

В личке могу дать ссылки на вполне себе востребованные продукты. Не уверен что оно тебе надо, конечно... ХЗ что у тебя за проблемы с самооценкой на почти пятом десятке, но от выделенного несет просто комплексами какими-то. Позволю себе впредь игнорить подобный информационный мусор.

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

M>К гипотезе — никак. Относится к заголовку.
M>Мне, например (а под "нам" в заголовке я понял и себя в том числе), не нравится.
Ну так это же наброс, тут так положено

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

V>Ну, право, это как критиковать сегодня морально устаревший набор кодов Интел-совместимых процессоров, со всеми их расширениями SSEx, где итоговая бинарная кодировка одна из САМЫХ НЕОПТИМАЛЬНЫХ В ИНДУСТРИИ! И чё??? Да ничё. Все понимают, никто и не спорит, но это никого не парит.
Это должно парить разработчиков CPU, нет?
На всякий случай напомню вам посмотреть в заголовок топика и перечитать моё сообщение, на которое вы отвечаете.

V>Ну, вообще-то, в той информации достоверно прослеживаются уникальные ключи и связи. Таки стоит взглянуть на схему базы — она относительно несложная.
О да. Какие-то 100 таблиц.

V>Т.е. реляции предоставляются предметной областью, поэтому огульно высмеять её не получится никак, увы.
Конечно же получится. Из "предметной области" там только две таблицы (плюс одна со связями). Всё остальное — чистая придумка мегаархитекторов.

V> Можно лишь поспорить относительно отдельных таблиц и связей. Я соглашусь только с иронией по поводу представления UI, но блин, в сотый раз оговорюсь, что эта ирония бессмыслена изначально, бо с выходом самой первой версии инсталлера в его SDK был тул по визуальному редактированию и тестированию UI.
Тул здесь совершенно ни при чём. Речь о том, что негодна сама идея реляционного описания UI.
Во-первых, это новый стандарт, требующий разработки отдельного тула, который стоит денег. Во-вторых, этот стандарт сразу ещё более ограниченный, чем даже dialog templates, т.к. не допускает расширения.
Хорошая платформа — это та, где для объём рукописного кода линеен относительно "площади поверхности". А в MSI для того, чтобы добавить на форму один контрол, не предусмотренный реляционной структурой, надо полностью отказаться от стандартного UI и воспроизводить и тестировать весь boilerplate руками.
С точки зрения пользователя такое решение — спорно. С точки зрения архитектуры — некомпететно.

V>Аналогично языка представления зависимостей. Он полон в декларативном смысле в терминах ВСЕХ объектов, описываемых базой инсталлера. Поэтому, да, некие вещи, выходящие за рамки информации, оперируемой инсталлерами, в нем описать нереально. Но это и хорошо — иначе бы это была дыра в безопасности.
Вы сегодня решили побить рекорд плотности чуши на одно сообщение? Включение custom action, которые выполняются под elevated privileges — это не дыра в безопасности, а описание в Condition "вещей, выходящих за рамки информации, оперируемой инсталлерами" — дыра? Поздравляю.

V>Мы используем Wise для чего-то уникального и только для совсем типовых пакетов — WiX, так что ничего сказать не могу. Последний раз, когда я пользовался InstallShield в 2003-м, он полностью удовлетворял всем моим нуждам.
Это много говорит о ваших нуждах. Кроме того, в 2003 вы запросто могли использовать InstallShield в режиме wrapper. Был у них такой подход одно время: их самопальный инсталлер тупо заворачивался в один transient компонент в MSI, который был, фактически, только запускальщиком инсталляции.

V>Я изучал подробно, но для чуть других целей — для целей генерирования скриптов автоматической установки софта.
В прошлый раз вы, помнится, "подробно изучали исходники SQL Server". На этот раз вы решили изучить устройство MSI, чтобы научиться писать скрипт, вызывающий msiexec.exe с нужными ключами? Похвально, похвально.

V>Нет, это ты спросил, как обойтись без ВСЕЙ "наркоманской" базы, я тебе подсказал. Тебе достаточно использовать ту её часть, где реляционное представление как нельзя к месту. Ну вот подыграл твоему "чувству прекрасного", не более того.
Ну, безо всей, как выясняется, обойтись нельзя. Вы же в курсе, что если у ваших компонентов есть понятие версии, то без файлов обойтись никак не удастся? Или этот уровень подробностей остался за пределами вашего "подробного изучения"?

V>Ну тогда опять и снова для особо одарённых — я подсказал простой способ получения достоверно работающего результата на имеющемся почти у всех девелоперов инструментарии. Это был ответ на "ай-ай, проблемы с custom actions". )))
Вы подсказали простой способ написать hello world. Спасибо, конечно, но этот этап я давно прошёл.

V>Можно подробнее — в чем именно геморрой?
В том, чтобы написать custom action, который корректно отрабатывает все режимы.
Вы почитайте немножко вот здесь: http://msdn.microsoft.com/en-us/library/aa368070(v=vs.85).aspx

V>Я понимаю для чего нужен WiX, но вижу непонимание у тебя. Этот DSL всё еще низкоуровневый, он плохо маскирует низлежащую платформу, поэтому пользоваться им напрямую для чего-то повторяемого — глупо.
Как раз им и пользуются. В MSI сделать повторно используемый custom action практически невозможно. А в WiX их дофига, и можно добавлять свои: http://wixtoolset.org/documentation/manual/v3/customactions/

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

V>>Основная польза от MSI-АПИ в иерархии продукт -> компонент.
S>И от этой же иерархии — основной вред. Вы в курсе, как устроен инсталлятор MS SQL Server, начиная примерно с 8.0? Если нет — то вот вам домашнее задание: выразить в терминах Windows Installer сосуществование нескольких инстансов SQL Server, при этом они могут быть как различных версий, так и одинаковых.

Кста, вот причина этого бестолкового спора. В непонимании, что есть инсталляция ПО с т.з. ОС.
Для ОС установка SQL-сервера — это установка, грубо говоря, бинарных файлов (и вспомогательных для их работы). Поэтому во время установки надо обыграть лишь существование различных бинарных версий сервера, а это прекрасно обыгрывается.

А всякие "инстансы", сидящие на разных портах или разных ключах именованных каналов (или еще на каком транспорте) — это сугубо прикладная хрень, которая обыгрывается утилитами администрирования SQL-сервера. Создание и удаление инстансов вовсе не требует переустановки бинарного образа программы SQL-сервака.

То бишь, по классике жанра это может быть сделано ПОСЛЕ инсталляции. Автоматом запустить утилиту конфигурирования инстансов сервака после его установки не сложно, ИМХО.

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

C>При том, что на вражеских платформах типа Линукса это же делается без особых проблем.

Давай конкретней, что вызывает проблемы в MSI и что делается легко в том же RPM?
А то, сдается мне, что ты пытаешься простой сценарий в RPM сравнить со сложным в MSI.
Как по мне, то что-то более-менее нетривиальное в RPM — еще больший ад.

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

C>>При том, что на вражеских платформах типа Линукса это же делается без особых проблем.
V>Давай конкретней, что вызывает проблемы в MSI и что делается легко в том же RPM?
Да банально сделать галочки "установить сервис"/"запускать сервис при запуске"/"запустить сейчас" с полем ввода для имени сервиса. С валидацией и возможностью unattended installation. Потом ещё указание каталога для файлов лога и настройки уровня логгирования.

Это то что я лично делал, в обоих системах.

V>А то, сдается мне, что ты пытаешься простой сценарий в RPM сравнить со сложным в MSI.
V>Как по мне, то что-то более-менее нетривиальное в RPM — еще больший ад.
В DEB всё просто — берёшь и пишешь простой shell-код. Вопросы задаются с помощью удобной и простой диалоговой системы, ответы которой могут скриптоваться.

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

V>Кста, вот причина этого бестолкового спора. В непонимании, что есть инсталляция ПО с т.з. ОС.
V>Для ОС установка SQL-сервера — это установка, грубо говоря, бинарных файлов (и вспомогательных для их работы). Поэтому во время установки надо обыграть лишь существование различных бинарных версий сервера, а это прекрасно обыгрывается.
Это вы, наверное, с Linux перепутали. Для windows установка SQL-сервера — это, грубо говоря, установка бинарных файлов, прописывание большого количества данных в реестр, регистрация сервисов и их зависимостей, переаттач существующих баз данных, настройка w3c сервисов и правил windows firewall и много чего ещё.

V>Создание и удаление инстансов вовсе не требует переустановки бинарного образа программы SQL-сервака.
Неважно, чего она требует или не требует. "Установка бинарного образа" — это, простите, копирование файлов, и оно прекрасно делается при помощи шелл-команды copy. А инсталлятор в windows обязан привести систему в рабочее состояние — т.е. сделать все те вещи, которые по-вашему делаются "после" инсталляции.

V>То бишь, по классике жанра это может быть сделано ПОСЛЕ инсталляции. Автоматом запустить утилиту конфигурирования инстансов сервака после его установки не сложно, ИМХО.
Добро пожаловать в реальный мир, Нео. В настоящем инсталляторе настоящего SQL Server (а не того, который вы себе смело вообразили) пришлось прятать 16 product keys, чтобы обеспечить возможность ставить/удалять инстансы независимо друг от друга.

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

C>>>При том, что на вражеских платформах типа Линукса это же делается без особых проблем.
V>>Давай конкретней, что вызывает проблемы в MSI и что делается легко в том же RPM?
C>Да банально сделать галочки "установить сервис"/"запускать сервис при запуске"/"запустить сейчас" с полем ввода для имени сервиса. С валидацией и возможностью unattended installation. Потом ещё указание каталога для файлов лога и настройки уровня логгирования.

Через пропертя это всё делается и в MSI. Запусти себе инсталляху с явным указанием св-в.
Просто имено с unattended installation пакетов MSI я и возился очень плотно, ничего сверхъестественного не увидел.


C>Это то что я лично делал, в обоих системах.

Согласен только насчет установки сервиса. Но подобный "скелет" пакета MSI для установки сервисов можно сделать лишь однажды и использовать затем. Просто в MSI есть крайне удобная фишка — слияние нескольких пакетов в один. Этим стоит пользоваться.

V>>А то, сдается мне, что ты пытаешься простой сценарий в RPM сравнить со сложным в MSI.
V>>Как по мне, то что-то более-менее нетривиальное в RPM — еще больший ад.
C>В DEB всё просто — берёшь и пишешь простой shell-код. Вопросы задаются с помощью удобной и простой диалоговой системы, ответы которой могут скриптоваться.

Не разбирался с DEB, я спросил про RPM. Это де-факто самый популярный формат для серверных линухов, а мне тут как раз серверными сценариями и тыкали. Так вот, там такой же АД, но этот ад не структурный, а навязан предметной областью — много всяких подробностей и соглашений. В MSI тоже АД не из-за структуры (она тривиальна, ваще-то), а из-за огромного кол-ва пропертей и соглашений, которыми надо уметь оперировать.

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

V>Кста, вот причина этого бестолкового спора. В непонимании, что есть инсталляция ПО с т.з. ОС.
V>Для ОС установка SQL-сервера — это установка, грубо говоря, бинарных файлов (и вспомогательных для их работы). Поэтому во время установки надо обыграть лишь существование различных бинарных версий сервера, а это прекрасно обыгрывается.

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

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

0>Я лично участвовал в пяти проектах, которые развивались по этой схеме. Вот результаты:
0>1. Три полностью провалились (т.е. были отменены после того, как сожрали изрядно денег и не дали никакого полезного результата).
0>2. Один еле вытащили до состояния shippable-продукта (т.е. все обещанные плюшки от разработки платформы пошли лесом, оставив переусложненную и нестабильную кодовую базу, в которую были зарыты крупные деньги).
0>3. Один, участником которого я являюсь сейчас, так же борется за жизнь, но есть сильный риск того, что он повторит первый или второй сценарий.
0>Про случаи, о которых я знаю по наслышке, я рассказывать не буду, но их ещё больше.

Компания А., фреймворк Ф.?

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

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

E>Компания А., фреймворк Ф.?
Оно самое.
Это, наверное, самый эпичный пример из моей личной практики.

E>По сути вопроса, фреймворк писать прикольно, кажется, что делаешь большое дело, которое, когда выстрелит, все сразу поможет и все оценят. Гораздо интереснее, чем пилить боковой винтик какого-нибудь продукта, о котором, возможно, никто и не вспомнит.
E>С другой стороны, по опыту с фреймворком очень просто ошибиться в оценке трудоемкости. Обычно кажется, что все не так уж сложно
E>И в третьих, больше вероятность, что пригодятся знания темных уголков ЯП, которые в обычных прикладных задачах обычно не нужны. Например, С++ шаблоны хитрозавернутые. Я же их знаю, книжку читал. Но в прикладных задачах они обычно ни к чему. Вот сейчас напишем фреймворк, заодно и шаблоны применим.
По-моему, всё очень точно подмечено

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

V>>Кста, вот причина этого бестолкового спора. В непонимании, что есть инсталляция ПО с т.з. ОС.
V>>Для ОС установка SQL-сервера — это установка, грубо говоря, бинарных файлов (и вспомогательных для их работы). Поэтому во время установки надо обыграть лишь существование различных бинарных версий сервера, а это прекрасно обыгрывается.
S>Это вы, наверное, с Linux перепутали. Для windows установка SQL-сервера — это, грубо говоря, установка бинарных файлов, прописывание большого количества данных в реестр, регистрация сервисов и их зависимостей,

Это для любой более-менее большой программы так, при чем тут Линух?

S>переаттач существующих баз данных, настройка w3c сервисов и правил windows firewall и много чего ещё.

Смешно, ведь это выполняется утилитами и скриптами, входящими в состав пакета. Ты можешь позапускать их ручками при надобности. Всё это можно отнести к этапу конфигурирование/настройка. И это в ЛЮБОЙ ОС так.

V>>Создание и удаление инстансов вовсе не требует переустановки бинарного образа программы SQL-сервака.
S>Неважно, чего она требует или не требует. "Установка бинарного образа" — это, простите, копирование файлов, и оно прекрасно делается при помощи шелл-команды copy.

Это даже в Линухах не делается простым copy.
Твоя попытка держать всех за идиотов превращает обсуждение в цирк.


S>А инсталлятор в windows обязан привести систему в рабочее состояние — т.е. сделать все те вещи, которые по-вашему делаются "после" инсталляции.

Обалденная новость! Вот теперь уже мне охота спросить — что ты знаешь об установке сервисов в других ОС? ))) Как ты вообще себе представляешь что-либо иное, если что-то куда-то необходимо прописать, зачастую в уже имеющийся конфиг (грубо говоря, аналог некоей ветки реестра)?

Ты уверен, что обсуждаешь то, что надо обсуждать?


V>>То бишь, по классике жанра это может быть сделано ПОСЛЕ инсталляции. Автоматом запустить утилиту конфигурирования инстансов сервака после его установки не сложно, ИМХО.
S>Добро пожаловать в реальный мир, Нео. В настоящем инсталляторе настоящего SQL Server (а не того, который вы себе смело вообразили) пришлось прятать 16 product keys, чтобы обеспечить возможность ставить/удалять инстансы независимо друг от друга.

Может быть я ошибаюсь, но я не помню, чтобы SQL Server можно было установить через запуск какого-то отдельного пакета MSI. Последний раз плотно работал с 2003-м, мог запамятовать, но вроде бы запускается экзешник-программа установки, которая ставит как необходимые компоненты, так и конфигурирует/настраивает результат установки программы.

Ну и описанное — не реальный мир, а нелепые бока самого SQL Server, тупое наследие шестерки. В реальном мире для запуска нескольких копий сервиса не обязательно было плодить "инстансы". Многие серверные программы позволяют запускать несколько своих инстансов одновременно без переустановки — достаточно при запуске указать нужный конфиг/параметры.

Кароч, в кривой архитектуре инстансов MS SQL виноват MSI. Молодца!

(Зная твои манеры, если полезешь рассуждать в область регистрации windows service и прочие тривиально-решаемые вещи — пойдешь в игнор, без обид)

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

I> единожды установленный SQL сервер практически невозможно снести, что бы начисто. Это регистрация, читай патч, чуть не всего что есть в системе — конфиги, реестры и все подряд.

Многие программы гадят в реестре и что?

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

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

Антон, это бесполезно.

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

I>> единожды установленный SQL сервер практически невозможно снести, что бы начисто. Это регистрация, читай патч, чуть не всего что есть в системе — конфиги, реестры и все подряд.

V>Многие программы гадят в реестре и что?

V>Для того и нужен MSI, чтобы система достоверно знала, какие ветки реестра грохать. А SQL-севак лишь отчасти ставится через MSI, а еще приличную часть работы выполняется вне MSI, рукописным его экзешником-инсталлятором. Т.е. ты сам же привел хороший пример того, что бывает, когда установка идет "ручками" — получается хаос, как в эпоху до MSI.

Хаос не потому,что руками, а потому что типичная инсталяция сервера это несколько инстанцев одной или разных версий на одной тачке и каждая из которых патчит столько, сколько никому даже в страшном сне не приснится.

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

V>Это для любой более-менее большой программы так, при чем тут Линух?
При том, что в традиции Линукса "инсталляция" — это ровно копирование файлов + разрешение зависимостей. Всё остальное — "настройка". Это снижает планку требований к инсталлятору.

V>Смешно, ведь это выполняется утилитами и скриптами, входящими в состав пакета. Ты можешь позапускать их ручками при надобности. Всё это можно отнести к этапу конфигурирование/настройка. И это в ЛЮБОЙ ОС так.
Домашнее задание: сравнить функциональность инсталлятора MS SQL Server и пакета MySQL для дистрибутива по вашему выбору.

V>Обалденная новость! Вот теперь уже мне охота спросить — что ты знаешь об установке сервисов в других ОС? ))) Как ты вообще себе представляешь что-либо иное, если что-то куда-то необходимо прописать, зачастую в уже имеющийся конфиг (грубо говоря, аналог некоей ветки реестра)?
Я знаю, что ни в одной другой ОС архитекторам подсистемы деплоймента не пришло в голову засовывать информацию о продукте в реляционную БД. И, кстати, сама Microsoft везде, кроме десктопа, для деплоймента прекрасно обходится без аналогов MSI. Оказалось, что, скажем, дешевле разработать новый формат пакетов для плагинов Office 2013, чем допилить Windows Installer.

V>Ты уверен, что обсуждаешь то, что надо обсуждать?
Отож.

V>Может быть я ошибаюсь, но я не помню, чтобы SQL Server можно было установить через запуск какого-то отдельного пакета MSI. Последний раз плотно работал с 2003-м, мог запамятовать, но вроде бы запускается экзешник-программа установки, которая ставит как необходимые компоненты, так и конфигурирует/настраивает результат установки программы.
2003 версии SQL Server не существует. Конечно же, вы запускали екзешник — setup.exe, оболочку инсталляции. Её задача — выбрать нужные MSI файлы для запуска.

V>Ну и описанное — не реальный мир, а нелепые бока самого SQL Server, тупое наследие шестерки.
Прекратите позориться. В шестёрке, как и в семёрке, не было никаких инстансов вообще. Side-by-side режим появился только с 2000й версии.

V>Кароч, в кривой архитектуре инстансов MS SQL виноват MSI. Молодца!
К архитектуре инстансов MS SQL претензий нет. А вот в том, что команде SQL Server пришлось упасть и отжаться, чтобы втиснуть потребности продукта в кривую архитектуру WI, виновата исключительно кривая архитектура WI.

"business-value" "KPI" "product launch" "sales boost" и вот это всё прочее "говна пирога"...
Это всё не о технической части, на это всем пофиг. Буизнесс вэлью ога)))