Здравствуйте, Eye of Hell, Вы писали:
EOH>>>Это нужно чтобы сделать корректный uninstall. _>>зачем иметь копии всех файлов, чтобы сделать uninstall ? Для uninstall-а должно быть достаточно базы с ИМЕНАМИ и путями этих файлов. _>>Для repair — да, но не все инсталляторы это умеют, однако все инсталляторы гадят на диске.
EOH>Не копии всех файлов, а исходный MSI — в котоом правила как ставилось и как будет удаляться. И код custom actions если надо. И какие-то временные файлы, которые могут понадобиться при анинсталле чего-нить тяжелого. В идеальном мире нужно делать MSI с разделяющимися боеголовками — "головная" часть которая только ставит / удаляет и .CAB с бинарниками. Тогда бы в операционке кэшировалась только головная часть. Но увы — это технически сложно, мало кто так делает.
Сам-то веришь в то, что пишешь? Какие еще "временные файлы, которые могут понадобиться при анинсталле чего-нить тяжелого"??? Сам ведь только что придумал. Нет там никаких временных файлов. Единственный файл, который может понадобится, это простой текстовый файл с примерно таким содержимым:
Разрегистрировать xxx.ocx, если на нее нет ссылок
Удалить xxx.yyy
Удалить каталог zzz если он пуст
Удалить папку с настройками, если при удалении выбрано "не сохранять настройки"
Удалить ветку реестра rrr
...
На кой для этих действий исходный MSI??? Просто "чтобы было"? И на самом деле файл этот бинарный, и большинству инсталляторов его с головой хватает. Кроме него нужна только программа, которая этот файл "интерпретирует" и выполняет заданные действия. И только MSI считает, что "а... винчестеры сейчас дешевые, пусть пользователь раскошеливается на мою тупость". Размеры бэкапов ведь тоже будут больше. Тут даже уже не в "больше" дело, а в "дольше делать и восстанавливать".
PS: И ты так и не ответил на вопрос, почему это все надо хранить на системном диске вместе с системой, а не спросить в нужный момент "Дайте путь к каталогу с инсталляцией". Нечего ответить?
D>Сам-то веришь в то, что пишешь? Какие еще "временные файлы, которые могут понадобиться при анинсталле чего-нить тяжелого"??? Сам ведь только что придумал.
А вот и неправда ваша, батенька. Я несколько лет делал MSI для продуктов компании и в целом неплохо представляю как там что работает.
D>Нет там никаких временных файлов. Единственный файл, который может понадобится, это простой текстовый файл с примерно таким содержимым: D>
D>Разрегистрировать xxx.ocx, если на нее нет ссылок
D>Удалить xxx.yyy
D>Удалить каталог zzz если он пуст
D>Удалить папку с настройками, если при удалении выбрано "не сохранять настройки"
D>Удалить ветку реестра rrr
D>...
D>
D>На кой для этих действий исходный MSI??? Просто "чтобы было"? И на самом деле файл этот бинарный, и большинству инсталляторов его с головой хватает. Кроме него нужна только программа, которая этот файл "интерпретирует" и выполняет заданные действия. И только MSI считает, что "а... винчестеры сейчас дешевые, пусть пользователь раскошеливается на мою тупость". Размеры бэкапов ведь тоже будут больше. Тут даже уже не в "больше" дело, а в "дольше делать и восстанавливать".
Я уже написал выше что в целом весь MSI не нужен. Но делать разделяющиеся боеголовки — технически сложно, а винты — дешевые.
D>PS: И ты так и не ответил на вопрос, почему это все надо хранить на системном диске вместе с системой, а не спросить в нужный момент "Дайте путь к каталогу с инсталляцией". Нечего ответить?
Ну я как бы не сотрудник Майкрософт и их адвакатурой не занимаюсь . Как я уже писал, то в целом не нужно хранить на системном диске. Но для авторов MSI такое решение — наиболее технически простое. А решение "дайте путь к каталогу с инсталляцией" — оно тоже применяется. Никогда не встречали невозможность сделать uninstall потому на запрос винды "\\temserver\\share\\product.msi is not available, please specify file path" ответить нечего?
Здравствуйте, Eye of Hell, Вы писали:
D>>Сам-то веришь в то, что пишешь? Какие еще "временные файлы, которые могут понадобиться при анинсталле чего-нить тяжелого"??? Сам ведь только что придумал.
EOH>А вот и неправда ваша, батенька. Я несколько лет делал MSI для продуктов компании и в целом неплохо представляю как там что работает.
И? Какие же это "временные файлы, которые могут понадобиться при анинсталле чего-нить тяжелого"? Что ж из тебя клещами нужно вытягивать все...
[skip] EOH>Ну я как бы не сотрудник Майкрософт и их адвакатурой не занимаюсь . Как я уже писал, то в целом не нужно хранить на системном диске. Но для авторов MSI такое решение — наиболее технически простое. А решение "дайте путь к каталогу с инсталляцией" — оно тоже применяется. Никогда не встречали невозможность сделать uninstall потому на запрос винды "\\temserver\\share\\product.msi is not available, please specify file path" ответить нечего?
Только тупому MSI'ю при uninstall'e требуется исходный product.msi. Хотя нет, я не прав, — в данном конкретном случае сам MSI тут как раз не при чем, это "тупому", которому этот product.msi делал MSI. Но общий объем данных, которые хранит MSI в файлах на системном диске и в реестре однозначно не требуется. Тем более при uninstall'е.
Ты так и не ответил на вопрос — а что же собственно из этого product.msi (или другого) может понадобится при uninstall'е? Что конкретно?
PS: В подавляющем большинстве случаев инсталлятор на диске нужен для обеспечения фичи "установка по требованию" или "восстановлении (repair)". Эти фичи — изобретение MSI, только все равно не понятно, зачем вообще хранить все инсталляторы на системном диске, и почему бы не дать пользователю возможность выбрать хранить всю инсталляцию или нет и вообще где ее хранить. Вот это и есть тупость. И не надо повторять как мантру "диски сейчас дешевые". Про размер бэкапа и время, которое требуется на его создание и восстановление ты уже забыл по дороге, да? Хоть и пишешь "не сотрудник Майкрософт и их адвакатурой не занимаюсь", но именно этим и занимаешься...
D>И? Какие же это "временные файлы, которые могут понадобиться при анинсталле чего-нить тяжелого"? Что ж из тебя клещами нужно вытягивать все...
Ну всякое может понадобиться. Лично из моего опыта — в процессе uninstall доставался исполняемый файл third-party сервиса, который останавливал и удалял этот сервис. В custom action такое сделать не получится, потому как компонент не был доступен в исходниках и имел собственный закрытый протокол общения со своим сервисом. Большие программные продукты — это как правило не только исполняемый файл. Это еще и разнообразные COM и OLE объекты, устанавливаемые в систему, сервисы, драйвера — много всего. Часть этого встроенными средствами MSI удалить проблемматично.
EOH>>Ну я как бы не сотрудник Майкрософт и их адвакатурой не занимаюсь . Как я уже писал, то в целом не нужно хранить на системном диске. Но для авторов MSI такое решение — наиболее технически простое. А решение "дайте путь к каталогу с инсталляцией" — оно тоже применяется. Никогда не встречали невозможность сделать uninstall потому на запрос винды "\\temserver\\share\\product.msi is not available, please specify file path" ответить нечего?
D>Только тупому MSI'ю при uninstall'e требуется исходный product.msi. Хотя нет, я не прав, — в данном конкретном случае сам MSI тут как раз не при чем, это "тупому", которому этот product.msi делал MSI. Но общий объем данных, которые хранит MSI в файлах на системном диске и в реестре однозначно не требуется. Тем более при uninstall'е.
Не требуется. Я уже несколько раз писал, что хранят MSI целиком не потому что это кто-то требует, а потому что делить MSI на "требуемую" и "не требуемую" части — технически сложно. Некоторые производители так делают, но таких меньшинство.
D>Ты так и не ответил на вопрос — а что же собственно из этого product.msi (или другого) может понадобится при uninstall'е? Что конкретно?
Информация uninstall sequence. Код и модули для custom actions, если они используются. Бинарные данные, если они нужны для uninstall.
D>PS: В подавляющем большинстве случаев инсталлятор на диске нужен для обеспечения фичи "установка по требованию" или "восстановлении (repair)". Эти фичи — изобретение MSI, только все равно не понятно, зачем вообще хранить все инсталляторы на системном диске, и почему бы не дать пользователю возможность выбрать хранить всю инсталляцию или нет и вообще где ее хранить.
Кэшировать или не кэшировать MSI — это собственно говоря флажек в нем самом. Пользователь может выбрать место для кэширования и включит / отключить его через установку соответствующих MSI Property и политик.
D>Вот это и есть тупость. И не надо повторять как мантру "диски сейчас дешевые". Про размер бэкапа и время, которое требуется на его создание и восстановление ты уже забыл по дороге, да? Хоть и пишешь "не сотрудник Майкрософт и их адвакатурой не занимаюсь", но именно этим и занимаешься...
Я подозреваю, что большинство пользователей не делают полный backup жесткого диска. Для того же Dropbox индифферентно что там винда закэшировала. Также я подозреваю, что если пользоватль делает регулярные бэкапы всего диска и для него критичен размер папок Windows — то он вполне может спросить на superuser.com и там ему расскажут и как кэширование MSI отключить, и restore point и много всего еще полезного для оптимизации дискового пространства.
Здравствуйте, Eye of Hell, Вы писали:
D>>И? Какие же это "временные файлы, которые могут понадобиться при анинсталле чего-нить тяжелого"? Что ж из тебя клещами нужно вытягивать все...
EOH>Ну всякое может понадобиться. Лично из моего опыта — в процессе uninstall доставался исполняемый файл third-party сервиса, который останавливал и удалял этот сервис.
Ты сам себе противоречишь. Исполняемый файл сервиса уже есть на диске (иначе что же ты собрался останавливать?) и доставать его еще раз из инсталляционного пакета это "как бэ мягко говоря лишнее". Даже в клинических случаях (если сервис сам не поддерживает остановку/удаление) "sc stop MyService & sc delete MyService" никто не отменял. Но и в этом случае наличие исходного пакета не нужно. Вообще.
EOH>В custom action такое сделать не получится, потому как компонент не был доступен в исходниках и имел собственный закрытый протокол общения со своим сервисом. Большие программные продукты — это как правило не только исполняемый файл. Это еще и разнообразные COM и OLE объекты, устанавливаемые в систему, сервисы, драйвера — много всего. Часть этого встроенными средствами MSI удалить проблемматично.
Может быть. Но ты так и не ответил на вопрос — зачем нужна полная инсталляция на системном диске? Кто мешал написать простую программу, которая все это бы делала и лежала в каталоге с установленной программой, если уж процесс uninstall'а в данном конкретном случае настолько сложен? Никто говоришь не мешал? В остальных же 99,9% случаев это просто не нужно. И таки если MSI настолько убогий для твоих инсталляций, то зачем же ты им пользуешься? Риторический вопрос...
[skip] D>>Ты так и не ответил на вопрос — а что же собственно из этого product.msi (или другого) может понадобится при uninstall'е? Что конкретно?
EOH>Информация uninstall sequence. Код и модули для custom actions, если они используются. Бинарные данные, если они нужны для uninstall.
Так эту информацию хранят все инсталляторы, которые предусматривают uninstall! Понимаешь — все! И ее объем не идет ни в какое сравнение с объемом инсталлятора! И им не требуется наличие исходного инсталлятора на диске. Сюрприз что-ли?
[skip] EOH>Кэшировать или не кэшировать MSI — это собственно говоря флажек в нем самом. Пользователь может выбрать место для кэширования и включит / отключить его через установку соответствующих MSI Property и политик.
Да? И ты мне подскажешь как это сделать, например, для MSO2007, MSO2010, VS2008, VS2010? Правда? И оно будет работать? Что-то мне сомнительно... Для MSO2003 я и сам делал, но вот все остальные просто не работают.
[skip] EOH>Я подозреваю, что большинство пользователей не делают полный backup жесткого диска. Для того же Dropbox индифферентно что там винда закэшировала. Также я подозреваю, что если пользоватль делает регулярные бэкапы всего диска и для него критичен размер папок Windows — то он вполне может спросить на superuser.com и там ему расскажут и как кэширование MSI отключить, и restore point и много всего еще полезного для оптимизации дискового пространства.
Я не знаю, что там за DropBox, но бэкап всего системного диска как бы требует записи всей информации, которая на системном диске. И ты уверен, что можешь решать за всех пользователей делать ли им полный бэкап системы? И да — давай, расскажи мне как отменить кэширование MSI. Мне правда интересно.
Вобщем, я тебя понял — ты тоже понятия не имеешь зачем же нужен инсталляционный пакет при uninstall'е. Нет, конечно можно придумать (фактически высосать из пальца) ситуацию когда это может понадобиться. Только тут же можно будет придумать и несколько решений, чтобы этого не было нужно. Непонятно только с чем ты собственно не согласен и что пытаешься сказать.
Здравствуйте, mike_rs, Вы писали:
_>зачем иметь копии всех файлов, чтобы сделать uninstall ? Для uninstall-а должно быть достаточно базы с ИМЕНАМИ и путями этих файлов.
Некоторые юзеры любят удалять с диска каталог с программой. Именно против таких бойцов инсталлеры и прячут в системный каталог.
Здравствуйте, мыщъх, Вы писали:
М>винде инсталляция студии это цирк. во-первых, нужна не только студия. там много чего нужно еще кроме нее.
Все что нужно для самой студии ставится из единого инсталлера.
М> во-вторых, инсталляция до ужаса интерактиваня и постоянно долбит дурацкими вопросами, вынуждая постоянно подходить к компьютеру и соображать что надавить для продолжения.
Какая то у тебя странная студия. Начиная с VS.NET инсталлер задает несколько вопросов в начале, и потом ставит все на полном автомате. Исключение составляют ошибки при инсталляции и, если ось не апдейтится, студия поставит несколько хотфиксов и попросит перезагрузиться.
Ну и unattended setup никто не отменял — http://msdn.microsoft.com/en-us/library/ee225237.aspx .
Здравствуйте, мыщъх, Вы писали:
BBI>>Ты судя по всему собираешь что то кроссплатформенное, которое писалось не под win изначально. М>например, лиса собирал. хрома. с хромом все гладко прошло, а с лисом появились проблемы, особенно при сборке старых версий.
Ну то есть ты понимаешь, что проблема не в студии, а в разработчиках лиса?
BBI>>Проекты писанные под винду прямыми руками собираются точно так же — одной кнопкой. М>FAR какими руками написал. плз, скажите куда надо нажать, чтобы его собрать?
Открываешь в VS2010 far.sln и жмешь кнопку Build. Или сразу msbuild
М> предполагается, что у меня его нет
Здравствуйте, hattab, Вы писали:
H> У меня просто вагон недоумения... Вот у меня на диске лежит 231 метр этого застарелого г..на, которое я бережно хранил для будущих установок, чтоб заново качать не пришлось, а новая ОС, значится, им побрезговала и хочет чтоб я надорвался заново качая это на моем 3G.
Старый инсталлятор фреймворка для новой оси не подойдет, так что не зря она качать хочет. А то что у тебя в качестве основного инета 3G — это ты ССЗБ.
Здравствуйте, Eugeny__, Вы писали:
E__>Ну, в Винде-то и не пакет, в том и разница. А опять же исполняемый файл.
Нет, в винде msi.
E__> Потому он влегкую может быть не совместим с той или иной версией, ибо в скриптах установки не предусмотрены изменения, сделанные в Восьмерке.
А в пакетах от предыдущих релизов убунты новые релизы предусмотрены?
D>Может быть. Но ты так и не ответил на вопрос — зачем нужна полная инсталляция на системном диске? Кто мешал написать простую программу, которая все это бы делала и лежала в каталоге с установленной программой, если уж процесс uninstall'а в данном конкретном случае настолько сложен? Никто говоришь не мешал? В остальных же 99,9% случаев это просто не нужно. И таки если MSI настолько убогий для твоих инсталляций, то зачем же ты им пользуешься? Риторический вопрос...
MSI используется потому что он нужен крупным корпоративным клиентам для unattended развертывания на тысячи компьютеров через доменные политики.
EOH>>Информация uninstall sequence. Код и модули для custom actions, если они используются. Бинарные данные, если они нужны для uninstall. D>Так эту информацию хранят все инсталляторы, которые предусматривают uninstall! Понимаешь — все! И ее объем не идет ни в какое сравнение с объемом инсталлятора! И им не требуется наличие исходного инсталлятора на диске. Сюрприз что-ли?
Я уже писал про разделяющиеся боеголовки?
EOH>>Кэшировать или не кэшировать MSI — это собственно говоря флажек в нем самом. Пользователь может выбрать место для кэширования и включит / отключить его через установку соответствующих MSI Property и политик. D>Да? И ты мне подскажешь как это сделать, например, для MSO2007, MSO2010, VS2008, VS2010? Правда? И оно будет работать? Что-то мне сомнительно... Для MSO2003 я и сам делал, но вот все остальные просто не работают.
Будет, скорее всего — ни разу не проверял. http://www.google.ru/search?q=MSI+cache
EOH>>Я подозреваю, что большинство пользователей не делают полный backup жесткого диска. Для того же Dropbox индифферентно что там винда закэшировала. Также я подозреваю, что если пользоватль делает регулярные бэкапы всего диска и для него критичен размер папок Windows — то он вполне может спросить на superuser.com и там ему расскажут и как кэширование MSI отключить, и restore point и много всего еще полезного для оптимизации дискового пространства. D>Я не знаю, что там за DropBox, но бэкап всего системного диска как бы требует записи всей информации, которая на системном диске. И ты уверен, что можешь решать за всех пользователей делать ли им полный бэкап системы? И да — давай, расскажи мне как отменить кэширование MSI. Мне правда интересно.
См. выше.
D>Вобщем, я тебя понял — ты тоже понятия не имеешь зачем же нужен инсталляционный пакет при uninstall'е. Нет, конечно можно придумать (фактически высосать из пальца) ситуацию когда это может понадобиться. Только тут же можно будет придумать и несколько решений, чтобы этого не было нужно. Непонятно только с чем ты собственно не согласен и что пытаешься сказать.
Он не нужен. Но сохранять его целиком — наиболее простое техническое решение чтобы иметь uninstall без проблем. Я в целом ничего не пытаюсь сказать — мне вас слушать интересно . Такая... хмм.. активная позиция О_О.
E__>>Ну, в Винде-то и не пакет, в том и разница. А опять же исполняемый файл.
НС>Нет, в винде msi.
Это, конечно, куда лучше, но все равно msi далеко не идеал. Описанные здесь костыли и отсутствие единого репозитария это доказывают. Может быть, когда-то это дело допилят до нормального единого менеджера установки — это сейчас в Виндах реально недостающая фишка, одна из очень немногих, кстати, если не брать религиозные и финансовые аспекты.
E__>> Потому он влегкую может быть не совместим с той или иной версией, ибо в скриптах установки не предусмотрены изменения, сделанные в Восьмерке.
НС>А в пакетах от предыдущих релизов убунты новые релизы предусмотрены?
Нет. И не должны, как и в Винде, кстати. Я вроде ничего такого не говорил, я просто озвучил, почему старый инсталлер может не подходить для новой версии.
Некоторые старые продукты нормально инсталлятся на новой версии(что в Винде, что в Линухах), но это не значит, что все так должны.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H> У меня просто вагон недоумения... Вот у меня на диске лежит 231 метр этого застарелого г..на, которое я бережно хранил для будущих установок, чтоб заново качать не пришлось, а новая ОС, значится, им побрезговала и хочет чтоб я надорвался заново качая это на моем 3G.
НС> Старый инсталлятор фреймворка для новой оси не подойдет, так что не зря она качать хочет.
Первый-то ставится
HC> А то что у тебя в качестве основного инета 3G — это ты ССЗБ.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>В убунтах имея на руках пакет ты в репу лезть не обязан, не так ли?
НС> Если у тебя пакет от старого релиза, то таки заставит. Нет, можно обойти проверку зависимостей, но результат накатывания такого пакета непредсказуем.
А при чем тут зависимости, если у меня все зависимые пакеты так же наличествуют?
НС>> H> У меня просто вагон недоумения... Вот у меня на диске лежит 231 метр этого застарелого г..на, которое я бережно хранил для будущих установок, чтоб заново качать не пришлось, а новая ОС, значится, им побрезговала и хочет чтоб я надорвался заново качая это на моем 3G.
НС>> Старый инсталлятор фреймворка для новой оси не подойдет, так что не зря она качать хочет.
H>Первый-то ставится
Значит, он не настолько зависим от системы. Джава тоже какая угодно ставится — но она вообще минимально контактирует с системой. Первый дотнет не использует тот же DirectX, в отличие от.
HC>> А то что у тебя в качестве основного инета 3G — это ты ССЗБ.
H>За МКАД'ом жизнь есть!
Да, да. Киев за МКАДом — жизнь ключем, интернеты быстрые.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E> НС>> Старый инсталлятор фреймворка для новой оси не подойдет, так что не зря она качать хочет.
E> H>Первый-то ставится
E> Значит, он не настолько зависим от системы. Джава тоже какая угодно ставится — но она вообще минимально контактирует с системой. Первый дотнет не использует тот же DirectX, в отличие от.
То есть таки сбываются прогнозы и МС начинает забивать на обратную совместимость? Ну тем хуже для МС
E> HC>> А то что у тебя в качестве основного инета 3G — это ты ССЗБ.
E> H>За МКАД'ом жизнь есть!
E> Да, да. Киев за МКАДом — жизнь ключем, интернеты быстрые.
E>> НС>> Старый инсталлятор фреймворка для новой оси не подойдет, так что не зря она качать хочет.
E>> H>Первый-то ставится
E>> Значит, он не настолько зависим от системы. Джава тоже какая угодно ставится — но она вообще минимально контактирует с системой. Первый дотнет не использует тот же DirectX, в отличие от.
H>То есть таки сбываются прогнозы и МС начинает забивать на обратную совместимость? Ну тем хуже для МС
Да это вроде не секрет. У меня на Семерке половина старых игр не идет вообще ни под каким соусом — приходится ребутаться под Убунтой, и играть из-под Вайна. Я всерьез подумываю над установкой виндового порта Вайна под Семерку, как бы абсурдно это не звучало.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E> H>То есть таки сбываются прогнозы и МС начинает забивать на обратную совместимость? Ну тем хуже для МС
E> Да это вроде не секрет. У меня на Семерке половина старых игр не идет вообще ни под каким соусом — приходится ребутаться под Убунтой, и играть из-под Вайна. Я всерьез подумываю над установкой виндового порта Вайна под Семерку, как бы абсурдно это не звучало.
. Как я уже писал, то в целом не нужно хранить на системном диске. Но для авторов MSI такое решение — наиболее технически простое. А решение "дайте путь к каталогу с инсталляцией" — оно тоже применяется. Никогда не встречали невозможность сделать uninstall потому на запрос винды "\\temserver\\share\\product.msi is not available, please specify file path" ответить нечего?
В остальных же 99,9% случаев это просто не нужно. И таки если MSI настолько убогий для твоих инсталляций, то зачем же ты им пользуешься? Риторический вопрос...
