依赖项和在 vs 安装程序 6 中手动添加 dll/ocx 之间有什么区别？
我正在使用 vs 安装程序为我的 vb6 应用程序构建安装包。 问题是我可以看到在项目资源管理器下有一个附加到我的 exe 文件的依赖项列表。
替代文本 http://img505.imageshack.us/img505/9696/croppercapture259lr8.png< /a>
在目标机器树视图上的文件系统下，我实际上可以将 dll/ocx 存储在文件夹或 Windows 系统文件夹本身中[左侧窗口]。
替代文本 http://img101.imageshack.us/img101/9224/croppercapture251qm1.png< /a>
所以我不明白的是..实际上有区别吗？ 如果我只是设置依赖项而没有将 dll 或 ocx 添加到文件夹或 win sys 文件夹中，那么 dll 也会自动复制吗？
i'm using vs installer to build a setup package for my vb6 app.
and the problem is i can see that under the project explorer there's a list of dependencies attached to my exe file.
alt text http://img505.imageshack.us/img505/9696/croppercapture259lr8.png
and under the file system on target machine treeview, i can actually store the dll/ocx on a folder or in the windows system folder itself[the left window].
alt text http://img101.imageshack.us/img101/9224/croppercapture251qm1.png
so what i don't understand is .. is there actually a difference?
if i just set the dependencies and didn't add the dll or ocx to the folder or win sys folder, does the dll automatically get copied over too?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不保证所有这些 dll 都会出现在安装该软件的系统上。 因此，它们需要包含在您的安装程序中。 从那里你有两个选择。
您可以将它们安装在 Windows 系统文件夹或应用程序文件夹中。 不同之处在于，如果您将它们安装在应用程序文件夹中，您可以在 XP 和 Vista 上进行设置，以便可以启动并并行运行具有不同版本组件的不同版本的软件。 将它们安装到系统文件夹中将破坏依赖旧版本组件的任何旧版本。
如果组件依赖于其他无法更新的组件，则在应用程序文件夹中安装很少会不起作用。 发生这种情况通常与 Microsoft 库有关。 多年来，他们在这个问题上已经做得更好了。
了解涉及并行执行的问题
您可以在此处详细 依赖项需要位于您的安装程序中，以便它们在 Windows 注册表中注册。 与大多数 .NET 程序集不同，任何 ActiveX/COM 应用程序都需要注册组件才能使用它，即使您使用 CreateObject 和 Variant 类型来访问它也是如此。
我承认整个过程很特殊，并且是 DLL Hell 故事的来源之一。 从 MSDN 文章开始，使用维基百科，当然还可以在这里提出进一步的问题。
It is not guaranteed that all those dlls will be present on the system that the software is being installed on. So they need to be included in your installer. From there you have two choices.
You can install them in your windows system folders or in your application folder. The difference is that if you install them in your application folder you can set things up on XP and Vista so that the different version of the software with different version of the components can be fired up and run side by side. Installing them into the system folder will break any older version that depend on older version of the components.
Installing in the application folder rarely doesn't work if a component depends on other components that can't be updated. When this occurs it is usually with with Microsoft libraries. They have gotten better over the years on this issue.
You can read more about the issues involving side by side execution here
Finally the dependencies need to be in your installer so that they are registered in the Windows Registry. Unlike most .NET assemblies any ActiveX/COM application needs to have the component registered in order to use it even if you are using CreateObject and Variant types to access it.
I will admit the whole process is idiosyncratic and is one of the sources for the stories about DLL Hell. Start with the MSDN article, use wikipedia, and of course ask further questions here.
对于普通的安装程序包，应用程序文件夹下通常不应该有“dlls”文件夹，但涉及许多因素（私有标准 DLL、Reg-Free COM 等）。 是的，依赖项已包含在内（除非您排除它们）。 它们每个都应该有一个属性来确定它们在目标系统上的安装位置。
该列表中还有许多组件无法通过这种方式重新分发，因为它们是依赖于操作系统的系统组件、MDAC 组件，或者未获得 redist 许可（例如 fm20.dll）。
遗憾的是，这是一个可以直接导致用户系统进入 DLL Hell 的包类型的示例。 解决此问题可能意味着研究 MS 知识库文章中的每个 MS 组件，以确定可以或应该重新分发哪些内容以及如何重新分发。
正确部署可能是一件很麻烦的事情。
You should usually not have a "dlls" folder under the app folder for a normal Installer package but there are many factors involved (private standard DLLs, Reg-Free COM, etc.). Yes, the dependencies get included (unless you exclude them). They should each have a property that determines where they install on the target systems.
You also have a number of components in that list that are either not redistributable this way because they are OS-dependent system components, MDAC components, or not licensed for redist (fm20.dll for example).
Sadly this is an example of the type of package that can lead directly to DLL Hell for your users' systems. Fixing this can mean researching every MS component in MS KB articles to determine what can or should be redistributed and how.
Deployment can be a messy business to get right.