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

Question

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

alt text http://img505.imageshack.us/img505/9696/croppercapture259lr8.png

и под файловую систему на целевой машине TreeView, я на самом деле может хранить DLL/OCX на папке или в самой системе окна папку [левое окно].

alt text http://img101.imageshack.us/img101/9224/croppercapture251qm1.png

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

Answer 1

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

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

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

Вы можете прочитать больше о проблемах, связанных с выполнением бока бокового here

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

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

Answer 2

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

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

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

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