Работаю в конторе которая выпускает с десяток софтверных продуктов. Разумеется есть куча повторно используемых внутри организации компонент. Вне моей организации повторное использование этих компонент неизвестно. Компоненты инсталлируются в каталог "c:\program files\фирма\common", продукты которые используют эти компоненты инсталлируются в "C:\program files\фирма\продукт". Все инсталляции и merge modules, через несколько лет после введения этого правила, наконец отладили, служба поддержки наконец привыкла, пользователи тоже знают.
По разным обстоятельствам задались сейчас вопросом — а правильно-ли это? Может быть, следуя тому как это делает Микрософт, стоит инсталлировать в "C:\program files\common files\фирма" ?
Просидел кучу времени в и-нете, пытаясь найти серьезный аргумент что-бы делать именно так. Единственно что удалось найти: http://msdn2.microsoft.com/en-us/library/ms954376.aspx, section “4. Install Shared Files to the Correct Locations”. Но это мне выглядит не более чем совет. Аргументов зачем надо именно так нет. Так-же нет аргументирования что случится если этому совету не следовать. В различных тестах на совместимость с Microsoft Vista тоже ничего по этому поводу не проверяется.
Может быть тут кто-нибудь знает зачем инсталлировать компоненты в "C:\program files\common files\фирма" ?
Здравствуйте, AlexanderDz, Вы писали:
AD>Может быть тут кто-нибудь знает зачем инсталлировать компоненты в "C:\program files\common files\фирма" ?
Я думаю, что для логического порядка. Что бы все общие файлы всех приложений хранились центролизованно. С таким же успехом можно спросить, зачем инсталлировать в "Program Files", ведь можно проинсталлировать в С:\<фирма>\.
Когда все приложения придерживаются единого стиля, то это проще администрировать.
Возможно в этих рекомендациях есть ещё и другой смысл, например связанный с безопасностью файлов.
К томуже следование рекомендациям минимизирует проблемы совместимости с будущими версиям ОС.
Здравствуйте, alexbirk, Вы писали:
A>Здравствуйте, AlexanderDz, Вы писали:
AD>>Может быть тут кто-нибудь знает зачем инсталлировать компоненты в "C:\program files\common files\фирма" ?
A>Я думаю, что для логического порядка. Что бы все общие файлы всех приложений хранились центролизованно.
Зачем??? Какую проблему это решает? Более того, это приводит к "распылению" частей продукта по разным каталогам.
Рассмотрим пример Adobe Reader 8.0. Практически все файлы общим объемом 113 мегабайт установлены в "C:\Program Files\Adobe\Reader 8.0". Жалкие 3 файла общим объемом 1 мегабайт установлены в "C:\Program Files\Common Files\Adobe\Acrobat\ActiveX\". И мы все знаем что эти три файла совершенно бесполезны без тех 113 мегабайт. Пути к этим всем файлам записываются в registry.
A>С таким же успехом можно спросить, зачем инсталлировать в "Program Files", ведь можно проинсталлировать в С:\<фирма>\.
Ответ прост: В каталог С:\<фирма>\ могут писать кто угодно, соответственно происходит нарушение безопасности. Значит, туда устанавливать нельзя.
A>Когда все приложения придерживаются единого стиля, то это проще администрировать. A>Возможно в этих рекомендациях есть ещё и другой смысл, например связанный с безопасностью файлов.
A>К томуже следование рекомендациям минимизирует проблемы совместимости с будущими версиям ОС.
На все что лежит в "C:\Program Files\", по умолчанию, распространяются одинаковые права. Никаких намеков на различие мне найти не удалось. Поскольку в "C:\Program Files\Common Files" лежат исполняемые модули так-же как и в "C:\Program Files\" мне очевидно что правила к ним будут применяться те-же самые.
Рекомендации Майкрософта меняются как погода. Многие наши продукты пережили несколько штук таких рекомендаций. Под данной рекомендацией нет четкого технического, юридического или иного обоснования. Соответственно, и срок жизни этой рекомендации непонятный.
Кстати, в самом MS нет единого мнения — в одном месте этот каталог записывается как "C:\Program Files\Common Files" в другом месте как "C:\Program Files\Common", а в третьем "C:\Program Files\Shared Files". Да, я знаю что следует испольвать SHGetFolder или SHGetSpecialFolder или что там еще под Vista и после нее.
Здравствуйте, AlexanderDz, Вы писали:
AD>Здравствуйте, alexbirk, Вы писали:
A>>Здравствуйте, AlexanderDz, Вы писали:
AD>>>Может быть тут кто-нибудь знает зачем инсталлировать компоненты в "C:\program files\common files\фирма" ?
A>>Я думаю, что для логического порядка. Что бы все общие файлы всех приложений хранились центролизованно.
AD>Зачем??? Какую проблему это решает? Более того, это приводит к "распылению" частей продукта по разным каталогам.
Наверное, предполагается, что скажем некоторая фирма ABC поставляет свой продукт, для работы которого нужны компоненты производимые другой фирмой XYZ. и другая фирма DEF использует компоненты XYZ. И для того, чтобы компоненты не дублировались в каталогах, относящихся к ABC и DEF, они выносятся в Common Files.
Т.е. вместо
Здравствуйте, dshe, Вы писали:
D>Здравствуйте, AlexanderDz, Вы писали:
AD>>Здравствуйте, alexbirk, Вы писали:
A>>>Здравствуйте, AlexanderDz, Вы писали:
AD>>>>Может быть тут кто-нибудь знает зачем инсталлировать компоненты в "C:\program files\common files\фирма" ?
A>>>Я думаю, что для логического порядка. Что бы все общие файлы всех приложений хранились центролизованно.
AD>>Зачем??? Какую проблему это решает? Более того, это приводит к "распылению" частей продукта по разным каталогам.
D>Наверное, предполагается, что скажем некоторая фирма ABC поставляет свой продукт, для работы которого нужны компоненты производимые другой фирмой XYZ. и другая фирма DEF использует компоненты XYZ. И для того, чтобы компоненты не дублировались в каталогах, относящихся к ABC и DEF, они выносятся в Common Files. D>Т.е. вместо D>
D>Насколько это практично с учетом несовпадения версий XYZ — это другой вопрос.
Если компоненты фирмы XYZ обладают COM интерфейсом, и установлены в каталог
C:\Program Files\XYZ\<компонента версии 1>
Чем этот каталог хуже чем
C:\Program Files\Common Files\XYZ\<компонента версии 1>
Установка должна быть реализована merge module-м который поставляется фирмой XYZ.
В случае .NET все регистрируется в GAC — тоже только одна копия. А-а-а-а понял! Если компонента классический DLL, тогда установка в "Common Files" позволит съэкономить несколько мегабайт на современных, стремящимся к терабайтам винчестерам. Тоже не много смысла. А в случае
D>Насколько это практично с учетом несовпадения версий XYZ — это другой вопрос.
Здравствуйте, AlexanderDz, Вы писали:
AD>Здравствуйте, alexbirk, Вы писали:
A>>Здравствуйте, AlexanderDz, Вы писали:
AD>>>Может быть тут кто-нибудь знает зачем инсталлировать компоненты в "C:\program files\common files\фирма" ?
A>>Я думаю, что для логического порядка. Что бы все общие файлы всех приложений хранились центролизованно.
AD>Зачем??? Какую проблему это решает? Более того, это приводит к "распылению" частей продукта по разным каталогам.
Это позволяет однозначно определить то, где находятся общие файлы, которые могут быть использованы другими приложениями других фирм. А путь установки основного приложения может меняться пользователем.
Под общими файлами подразумеваются не только общие библиотеки, но и разные ресурсы, графика, звуки и т.д. Опять же, когда общие файлы хранятся центролизованно то они легко поддаются обновлению (исправление ошибок).
. . .
AD>Рекомендации Майкрософта меняются как погода. Многие наши продукты пережили несколько штук таких рекомендаций. Под данной рекомендацией нет четкого технического, юридического или иного обоснования. Соответственно, и срок жизни этой рекомендации непонятный.
Рекомендации меняются потому что прогресс не стоит на месте. Это именно рекомендации, а не стандарт.
Всё равно лучше по возможности следовать рекомендациям, чем им не следовать, т.к. в основной своей массе они не сильно меняются.
AD>Кстати, в самом MS нет единого мнения — в одном месте этот каталог записывается как "C:\Program Files\Common Files" в другом месте как "C:\Program Files\Common", а в третьем "C:\Program Files\Shared Files". Да, я знаю что следует испольвать SHGetFolder или SHGetSpecialFolder или что там еще под Vista и после нее.
Помоему тут дело не в разных мнениях, а в не достаточном контроле качества внутри MS по некоторым продуктам. Попадаются случаи куда хуже...
[...]
AD>>>>Может быть тут кто-нибудь знает зачем инсталлировать компоненты в "C:\program files\common files\фирма" ?
A>>>Я думаю, что для логического порядка. Что бы все общие файлы всех приложений хранились центролизованно.
AD>>Зачем??? Какую проблему это решает? Более того, это приводит к "распылению" частей продукта по разным каталогам.
A>Это позволяет однозначно определить то, где находятся общие файлы, которые могут быть использованы другими приложениями других фирм. А путь установки основного приложения может меняться пользователем. A>Под общими файлами подразумеваются не только общие библиотеки, но и разные ресурсы, графика, звуки и т.д. Опять же, когда общие файлы хранятся центролизованно то они легко поддаются обновлению (исправление ошибок).
Для template-s документов есть отдельные каталоги. Языковые ресурсы для исполняемых модулей должны лежать рядом с модулями. Графика, звуки... может быть. Но слишком мало что-бы стоило париться. В случае моей конторы — их просто нет.
Все исполняемые модули все-равно регистрируются в registry и путями к ним занимается COM подсистема.
Обновлениями и исправлениями ошибок занимается Windows Installer — он специально для этого сделан.
Если уж на то пошло, если продукт полностью используется сторонними фирмами, чем плохо его устанавливать в "C:\program files\common files\фирма\продукт"
Здравствуйте, AlexanderDz, Вы писали:
AD>Здравствуйте, alexbirk, Вы писали:
AD>[...]
AD>>>>>Может быть тут кто-нибудь знает зачем инсталлировать компоненты в "C:\program files\common files\фирма" ?
A>>>>Я думаю, что для логического порядка. Что бы все общие файлы всех приложений хранились центролизованно.
AD>>>Зачем??? Какую проблему это решает? Более того, это приводит к "распылению" частей продукта по разным каталогам.
A>>Это позволяет однозначно определить то, где находятся общие файлы, которые могут быть использованы другими приложениями других фирм. А путь установки основного приложения может меняться пользователем. A>>Под общими файлами подразумеваются не только общие библиотеки, но и разные ресурсы, графика, звуки и т.д. Опять же, когда общие файлы хранятся центролизованно то они легко поддаются обновлению (исправление ошибок).
AD>Для template-s документов есть отдельные каталоги. Языковые ресурсы для исполняемых модулей должны лежать рядом с модулями. Графика, звуки... может быть. Но слишком мало что-бы стоило париться. В случае моей конторы — их просто нет.
AD>Все исполняемые модули все-равно регистрируются в registry и путями к ним занимается COM подсистема. AD>Обновлениями и исправлениями ошибок занимается Windows Installer — он специально для этого сделан.
Windows Installer не волшебник, он не сможет обновить общий файл, который находится в нескольких экземплярах в разных каталогах и поставляется с разными продкутами.
Пример:
Есть общий файл SharedLib.dll
Есть продукт Product1 и Product2, в поставку которых входит SharedLib.dll.
Если каждый продукт содержащий общую библиотеку будет помещать её в свой специфичный каталог, то в случае обнаружения ошибки в SharedLib.dll нужно обновлять оба продукта, т.к. каждый инсталлятор обновит только свою копию библиотеки.
Возникает также другая проблема. Я пришу свою программу, которая хочет использовать (динамически линковать) эту общую библиотеку и возникает вопрос, из какого каталога мне её использовать ? В результате мне приходится затачиваться на конкретный продукт Product1 или Product2, а не на общую библиотеку.
В качестве примера я привёл библиотеку, т.к. это наиболее типичный случай. Тоже самое может быть с любым видом файлов.
AD>Если уж на то пошло, если продукт полностью используется сторонними фирмами, чем плохо его устанавливать в "C:\program files\common files\фирма\продукт"
Потомучто в общем случае ПОЛЬЗОВАТЕЛЬ выбирает место, куда инсталлировать продукт. Например у меня на диске C: мало места и я хочу установить программу на диск D:. В результате большая часть программы будет на D:, а общие файлы поместятся в обедоступное место "<Common Files>".
Здравствуйте, alexbirk, Вы писали:
A>Здравствуйте, AlexanderDz, Вы писали:
AD>>Здравствуйте, alexbirk, Вы писали:
AD>>[...]
AD>>>>>>Может быть тут кто-нибудь знает зачем инсталлировать компоненты в "C:\program files\common files\фирма" ?
A>>>>>Я думаю, что для логического порядка. Что бы все общие файлы всех приложений хранились центролизованно.
AD>>>>Зачем??? Какую проблему это решает? Более того, это приводит к "распылению" частей продукта по разным каталогам.
A>>>Это позволяет однозначно определить то, где находятся общие файлы, которые могут быть использованы другими приложениями других фирм. А путь установки основного приложения может меняться пользователем. A>>>Под общими файлами подразумеваются не только общие библиотеки, но и разные ресурсы, графика, звуки и т.д. Опять же, когда общие файлы хранятся центролизованно то они легко поддаются обновлению (исправление ошибок).
AD>>Для template-s документов есть отдельные каталоги. Языковые ресурсы для исполняемых модулей должны лежать рядом с модулями. Графика, звуки... может быть. Но слишком мало что-бы стоило париться. В случае моей конторы — их просто нет.
AD>>Все исполняемые модули все-равно регистрируются в registry и путями к ним занимается COM подсистема. AD>>Обновлениями и исправлениями ошибок занимается Windows Installer — он специально для этого сделан.
A>Windows Installer не волшебник, он не сможет обновить общий файл, который находится в нескольких экземплярах в разных каталогах и поставляется с разными продкутами.
A>Пример: A>Есть общий файл SharedLib.dll A>Есть продукт Product1 и Product2, в поставку которых входит SharedLib.dll.
А также Side-by-side установка тоже придумана решать эту проблему.
[...]
AD>>Если уж на то пошло, если продукт полностью используется сторонними фирмами, чем плохо его устанавливать в "C:\program files\common files\фирма\продукт"
A>Потомучто в общем случае ПОЛЬЗОВАТЕЛЬ выбирает место, куда инсталлировать продукт. Например у меня на диске C: мало места и я хочу установить программу на диск D:. В результате большая часть программы будет на D:, а общие файлы поместятся в обедоступное место "<Common Files>".
Пользователь дома выбирает куда ему инсталлировать программу. А на работе, при установке mission critical приложений это делает администратор в соответствии с предписаниями организации. В этом случае на дисках находится достаточное количество места. Более того, для моих приложений как-раз жестоко требуется что-бы все стояло именно на C:. А с данными для программы пользователь разбирается сам.
Здравствуйте, AlexanderDz, Вы писали:
AD>Здравствуйте, alexbirk, Вы писали:
AD>[...]
AD>>>Если уж на то пошло, если продукт полностью используется сторонними фирмами, чем плохо его устанавливать в "C:\program files\common files\фирма\продукт"
A>>Потомучто в общем случае ПОЛЬЗОВАТЕЛЬ выбирает место, куда инсталлировать продукт. Например у меня на диске C: мало места и я хочу установить программу на диск D:. В результате большая часть программы будет на D:, а общие файлы поместятся в обедоступное место "<Common Files>".
AD>Пользователь дома выбирает куда ему инсталлировать программу. А на работе, при установке mission critical приложений это делает администратор в соответствии с предписаниями организации. В этом случае на дисках находится достаточное количество места. Более того, для моих приложений как-раз жестоко требуется что-бы все стояло именно на C:. А с данными для программы пользователь разбирается сам.
По моему мы обсуждаем идеалогию качественной установки ПО, а не конкретно ваши приложения и специфичные требования вашего заказчика. У разных организаций разные правила. В общем случае ПО не должно зависеть от пути установки. Даже Windows можно на D: установить
Здравствуйте, AlexanderDz, Вы писали:
AD>Пользователь дома выбирает куда ему инсталлировать программу. А на работе, при установке mission critical приложений это делает администратор в соответствии с предписаниями организации. В этом случае на дисках находится достаточное количество места. Более того, для моих приложений как-раз жестоко требуется что-бы все стояло именно на C:
Если ваше приложение не может пережить инсталляцию на диск, отличный от C:, то вопросы типа использования/неиспользования Common Files являются ненужной эзотерикой. Ухудшить инсталляцию вы уже не сможете
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, AlexanderDz, Вы писали:
AD>>Пользователь дома выбирает куда ему инсталлировать программу. А на работе, при установке mission critical приложений это делает администратор в соответствии с предписаниями организации. В этом случае на дисках находится достаточное количество места. Более того, для моих приложений как-раз жестоко требуется что-бы все стояло именно на C:
S>Если ваше приложение не может пережить инсталляцию на диск, отличный от C:, то вопросы типа использования/неиспользования Common Files являются ненужной эзотерикой. Ухудшить инсталляцию вы уже не сможете
Не стоит беспокоиться, мои системы успешно переживают установки на любые диски, каталоги, а также установки методом xcopy. Увы, в последнем случае надо выполнять ручками:
for /r %f in (*.dll) do @regsvr32 %f
Установку xcopy как раз трудно реализовать если половина программы должна лежать на другом диске по фиксированному пути.
Здравствуйте, alexbirk, Вы писали:
A>Здравствуйте, AlexanderDz, Вы писали:
AD>>Здравствуйте, alexbirk, Вы писали:
AD>>[...]
AD>>>>Если уж на то пошло, если продукт полностью используется сторонними фирмами, чем плохо его устанавливать в "C:\program files\common files\фирма\продукт"
A>>>Потомучто в общем случае ПОЛЬЗОВАТЕЛЬ выбирает место, куда инсталлировать продукт. Например у меня на диске C: мало места и я хочу установить программу на диск D:. В результате большая часть программы будет на D:, а общие файлы поместятся в обедоступное место "<Common Files>".
AD>>Пользователь дома выбирает куда ему инсталлировать программу. А на работе, при установке mission critical приложений это делает администратор в соответствии с предписаниями организации. В этом случае на дисках находится достаточное количество места. Более того, для моих приложений как-раз жестоко требуется что-бы все стояло именно на C:. А с данными для программы пользователь разбирается сам.
A>По моему мы обсуждаем идеалогию качественной установки ПО, а не конкретно ваши приложения и специфичные требования вашего заказчика. У разных организаций разные правила. В общем случае ПО не должно зависеть от пути установки. Даже Windows можно на D: установить
Я согласен с вашими замечаниями. Однако, как я уже обратил внимание выше, пути к файлам как из \program files\<фирма>\<продукт> так и из \program files\Common Files\<фирма>\<продукт> записываются в registry. Поскольку эти файлы обладают COM интерфейсом, доступ к файлам происходит черед CLSID. Таким образом, фактический путь к файлам уже не важен.
Случаи не COM интерфейса также были обсуждены.
С другой стороны, эта дискуссия инженеров, а не религиозных деятелей, слепо следующих догмам. Не так ли? Руководства тоже пишутся людьми которые делают ошибки и руководства стареют (как уже кто-то упомянул).
