Какова разница между зависимостями и вручную добавить dll / ocx в vs installer 6?

Question

Я использую vs installer для создания пакета установки для моего приложения vb6. и проблема в том, что я вижу, что в проводнике проекта есть список зависимостей, прикрепленных к моему exe-файлу.

альтернативный текст http://img505.imageshack.us/img505/9696/croppercapture259lr8 .png

и в файловой системе дерева дерева целевой машины я могу хранить dll / ocx в папке или в самой системной папке Windows [левое окно].

альтернативный текст http://img101.imageshack.us/img101/9224/croppercapture251qm .png

так что я не понимаю ... есть ли на самом деле разница? если я просто установил зависимости и не добавил dll или ocx в папку или в папку win sys, dll тоже автоматически копируется?

Answer 1

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

Вы можете установить их в системные папки Windows или в папку приложения. Разница в том, что если вы устанавливаете их в папку приложения, вы можете настроить их на XP и Vista, чтобы разные версии программного обеспечения с разными версиями компонентов можно было запускать и запускать рядом. Установка их в системную папку сломает любую более старую версию, которая зависит от более старой версии компонентов.

Установка в папку приложения редко не работает, если компонент зависит от других компонентов, которые не могут быть обновлены. Когда это происходит, это обычно происходит с библиотеками Microsoft. Они поправились за эти годы.

Подробнее о проблемах, связанных с параллельным выполнением, вы можете прочитать здесь

Наконец, зависимости должны быть в вашем установщике, чтобы они были зарегистрированы в реестре Windows. В отличие от большинства сборок .NET любое приложение ActiveX / COM должно иметь зарегистрированный компонент, чтобы использовать его, даже если вы используете для этого типы CreateObject и Variant.

Я признаю, что весь процесс уникален и является одним из источников для историй об DLL Hell. Начните со статьи MSDN, используйте Википедию и, конечно, задавайте дополнительные вопросы здесь.

Answer 2

Обычно у вас не должно быть "dlls" папка под папкой приложения для обычного установочного пакета, но здесь задействовано много факторов (частные стандартные DLL, Reg-Free COM и т. д.). Да, зависимости включаются (если вы не исключаете их). У каждого из них должно быть свойство, определяющее, где они устанавливаются в целевых системах.

У вас также есть ряд компонентов в этом списке, которые либо не распространяются таким образом, поскольку они являются системно-зависимыми компонентами системы, компонентами MDAC или не лицензированы для повторного распространения (например, fm20.dll).

К сожалению, это пример типа пакета, который может привести непосредственно к DLL Hell для систем ваших пользователей. Исправить это может означать исследование каждого компонента MS в статьях MS KB, чтобы определить, что можно или нужно распространять и как.

Развертывание может быть грязным делом, чтобы получить право.