Какова разница между зависимостями и вручную добавить dll / ocx в vs installer 6?
-
08-07-2019 - |
Вопрос
Я использую 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 тоже автоматически копируется?
Решение
Не гарантируется, что все эти библиотеки будут присутствовать в системе, в которой устанавливается программное обеспечение. Поэтому они должны быть включены в ваш установщик. Оттуда у вас есть два варианта. Р>
Вы можете установить их в системные папки Windows или в папку приложения. Разница в том, что если вы устанавливаете их в папку приложения, вы можете настроить их на XP и Vista, чтобы разные версии программного обеспечения с разными версиями компонентов можно было запускать и запускать рядом. Установка их в системную папку сломает любую более старую версию, которая зависит от более старой версии компонентов. Р>
Установка в папку приложения редко не работает, если компонент зависит от других компонентов, которые не могут быть обновлены. Когда это происходит, это обычно происходит с библиотеками Microsoft. Они поправились за эти годы. Р>
Подробнее о проблемах, связанных с параллельным выполнением, вы можете прочитать здесь а> р>
Наконец, зависимости должны быть в вашем установщике, чтобы они были зарегистрированы в реестре Windows. В отличие от большинства сборок .NET любое приложение ActiveX / COM должно иметь зарегистрированный компонент, чтобы использовать его, даже если вы используете для этого типы CreateObject и Variant. Я признаю, что весь процесс уникален и является одним из источников для историй об DLL Hell. Начните со статьи MSDN, используйте Википедию и, конечно, задавайте дополнительные вопросы здесь.
Другие советы
Обычно у вас не должно быть "dlls" папка под папкой приложения для обычного установочного пакета, но здесь задействовано много факторов (частные стандартные DLL, Reg-Free COM и т. д.). Да, зависимости включаются (если вы не исключаете их). У каждого из них должно быть свойство, определяющее, где они устанавливаются в целевых системах.
У вас также есть ряд компонентов в этом списке, которые либо не распространяются таким образом, поскольку они являются системно-зависимыми компонентами системы, компонентами MDAC или не лицензированы для повторного распространения (например, fm20.dll).
К сожалению, это пример типа пакета, который может привести непосредственно к DLL Hell для систем ваших пользователей. Исправить это может означать исследование каждого компонента MS в статьях MS KB, чтобы определить, что можно или нужно распространять и как.
Развертывание может быть грязным делом, чтобы получить право.