同一应用程序中可以加载不同版本的 DLL 吗？
我的应用程序使用一个版本的库 (a.dll)，我使用另一个 DLL(b.dll)，它又使用我使用的同一库 (a.dll) 的旧版本。我正在通过嵌入清单文件来构建应用程序。我使用的 DLL 也使用嵌入式清单文件。我的 WinSXS 文件夹中有两个版本的库。我的应用程序无法加载适当版本的 DLL。
拥有单独的清单文件（不嵌入 DLL）是否有助于解决问题？解决办法是什么？
My application uses one version of library (a.dll), I am using another DLL(b.dll) which in-turn uses older version of the same library (a.dll) that i use. I am building the application by embedding a manifest file. The DLL i use is also using a embedded manifest file. I am having both the versions of the library in my WinSXS folder. My application is not able to load the appropriate versions of DLLs.
Will having a separate manifest file (not embedding into DLL) help resolving the problem? What is the work around?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的情况正是 WinSxS 应该解决的情况。它应该可以工作。
或者：清单文件指向相同版本，或者其中一个清单文件未正确嵌入，或者
WinSxS 中的共享程序集是使用自动将 v1.0 请求重定向到 v1.1 的配置策略安装的
一些说明是需要：App.exe 和 b.dll 隐式链接到 a.dll？或者他们通过 LoadLibrary 加载它。
如果 B.DLL 使用 LoadLibrary 显式加载 A.DLL，则需要将 ISOLATION_AWARE_ENABLED 添加到预处理器定义中，以确保 B.DLL 进行的 LoadLibrary 调用在正确的激活上下文中查找。否则，它们将在由 EXE 清单创建的默认激活上下文的上下文中生成。
Your situation is exactly the situation WinSxS is supposed to solve. It should be working.
Either: The manifest files are pointing to the same version, or one of the manifest files is not embedded properly, or
The shared assembly in WinSxS was installed with a configuration policy that automatically redirects requests for v1.0 to v1.1
Some clarifications are needed: App.exe and b.dll are implicitly linked against a.dll? Or do they load it via LoadLibrary.
If B.DLL loads A.DLL explicitly using LoadLibrary then you need to add ISOLATION_AWARE_ENABLED to your pre-processor definitions to ensure that LoadLibrary calls made by B.DLL look in the correct activation context. Otherwise they will be made in the context of the default activation context which was created by the EXE's manifest.
这将取决于复制的 DLL 的作用以及它们的版本是否兼容。 （例如，它们都访问内存中的共享对象吗？如果是这样，很可能会发生问题。）
它还取决于这两个同名 DLL 的加载方式。如果它不是具有完整路径的显式 LoadLibrary ，那么事情可能无法正常工作。这里有一个正在进行的讨论：确定 DLL 的加载路径
一般来说，如果你幸运的话，它可能会起作用。如果可以的话，它可能会出现灾难性错误，这一事实是完全避免该问题的一个很好的理由。 （在最坏的情况下，您可以将其中一个模块托管在另一个进程中并代理对其的所有调用。理想情况下，只需能够在两个模块中使用相同的 DLL 版本即可。）
It will depend on what the duplicated DLLs do and if their versions are compatible. (e.g. Do they both access shared objects in memory? If so, there's a good chance something will blow up.)
It will also depend on how those two same-named DLLs are loaded. If it's anything other than an explicit LoadLibrary with a full path then things probably will not work. There's an ongoing discussion of this here: Determine the loaded path for DLLs
In general, it might work if you're lucky. The fact it may go catastrophically wrong is a good reason to avoid the issue entirely, if you can. (In the worst case, you could host one of the modules in another process and proxy all the calls to it. Ideally, just be able to use the same DLL version in both modules.)