[Lisabon]

halflife2,

Скорей всего проблема с удалением Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729. Пусть установит сборку ещё раз. Если ситуация не изменится и Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729 останется в списке, то проблема с удалением. Если проблема с удалением, то как вариант сначала воспользоваться ключом /DelVCAll, и если в списке остались Redistributable, то использовать для удаления Windows Installer CleanUp. Если и это не поможет, то надо ковырять реестр и искать, где запрещёны права доступа записи на определённую ветвь реестра связанной с Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.

[geepnozeex]

а нельзя ли переделать установщик ? а то у меня борода успевает отрасти пока установка происходит , при том что железо не загружено почти.
x64

[Lisabon]

Обновил сборки:

- Microsoft Visual C++ 2005-2008-2010-2012 Redistributable Package Hybrid x86 (11,55 МБ)
- Microsoft Visual C++ 2005-2008-2010-2012 Redistributable Package Hybrid x86 & x64 (22,75 МБ)

Что изменено:

- добавлены msi-заглушки:
· Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.0 False
· Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.0 False

[IRainman]

а нельзя ли переделать установщик ? а то у меня борода успевает отрасти пока установка происходит , при том что железо не загружено почти. »

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

На примерах: вот уже два апдейта подряд реальная разница между сборками это несколько симлинков и установка одного msi пакета-пустышки (заглушки) для 32х битных систем и двух для 64х битных, а ставятся они где по нескольку минут, а где вообще десятки минут. Помимо этого количество компонентов и, следовательно, время обработки будут в дальнейшем только расти

P.S. если никак нельзя переделать сам инсталлятор на вычисление разницы, предлагаю тогда выкладывать при каждом обновлении дополнительный "патчер" для последней обновки, всё легче жить будет

[Lisabon]

IRainman,

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

"Патчера" не будет.

Если не устраивает что-то, то пишите сами скрипт и создавайте свою сборку.

[IRainman]

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

Благодарю, теперь понятно в чём собственно проблема и понятно почему патчера не будет. В очередной раз Microsoft показывает нам необходимостью таких костылей, что проблема dll-hell до сих пор окончательно не решена, а нормальной версии хранилища компонентов они так и не сделали, печально, продолжаем жрать кактус.

P.S. А в пределах одной группы тоже нельзя как то процесс оптимизировать? Ну т.е. если изменения затрагивают только либы от 2012 студии, то только от неё и переставлять все версии? По идее тут уже проблем быть не должно или там всё настолько плохо и зависимости есть даже между разными мажорными версиями?

[Lisabon]

P.S. А в пределах одной группы тоже нельзя как то процесс оптимизировать? Ну т.е. если изменения затрагивают только либы от 2012 студии, то только от неё и переставлять все версии? По идее тут уже проблем быть не должно или там всё настолько плохо и зависимости есть даже между разными мажорными версиями? »

Нет, нельзя. Нельзя отследить, какая сборка моя или чужая, новая или старая использовалась в системе. Нельзя отследить в какой последовательности происходила установка. Нельзя установить, пытался кто-то самовольно распаковать мой инсталлятор и производил установку вручную в своей последовательности (были такие случаи).

[geepnozeex]

а нельзя ли переделать установщик ? а то у меня борода успевает отрасти пока установка происходит , при том что железо не загружено почти. »

имелась ввиду установка с нуля на голую систему. x64
вот есть конкурент - RuntimePack
он устанавливается в разы быстрее , но не содержит заглушек.

[Nun-Nun]

вот есть конкурент - RuntimePack »

Он не совсем конкурент. Многие используют вариант "RuntimePack Lite" + "MVC++ 2005-2008-2010-2012-2013 RP".

[Lisabon]

RuntimePack он устанавливается в разы быстрее , но не содержит заглушек. »

Вот именно, RuntimePack не содержит заглушек и не тратится время на установку заглушек, которых нет, а заглушек довольно много в Microsoft Visual C++ 05-08-10-12-13 Redistributable Package Hybrid.

Также RuntimePack не удаляет предыдущие версии Microsoft Visual C++ Redistributable Package, при условии, что они были установлены в системе, что тоже влияет на время установки.

К тому же, RuntimePack не устраняет существующую проблему:

сборка содержит MSI-заглушки от предыдущих версий Microsoft Visual C++ Redistributable Package, для того, чтобы инсталляторы программ, беспрепятственно производили установку, не требуя установленных в системе, старые версии Microsoft Visual C++ Redistributable Package.

Более того, RuntimePack весит гораздо больше, чем связка RuntimePack Lite + Microsoft Visual C++ 05-08-10-12-13 Redistributable Package Hybrid x64.
RuntimePack - 57.87 MB против Microsoft Visual C++ 05-08-10-12-13 Redistributable Package Hybrid x64 - 22.75 MB + RuntimePack Lite - 5.59 MB = 28.34 MB