我们包含了一个 3rd Party lib+DLL,最近在安装时造成了很多麻烦。使用dependencywalker,我们发现dll本身引用了两个不同版本的
MSVCR80.DLL:
Version 8.0.50727.4053 and
Version 8.0.50727.42
替代文本 http://img101.imageshack.us/img101/1734/dependencywalk2.jpg
在大多数情况下,安装使没有问题,即使我们不分发这两个版本。但在许多情况下,我们的安装无法启动。然后我们在 Windows 系统事件日志中从 SideBySide 管理器中找到消息:“DLL 版本不匹配”。在大多数情况下,这个问题可以通过安装 .NET 框架来解决(尽管我们不使用它)。但现在我们遇到一个情况,这没有帮助。
我知道解决方案是将两个版本安装为共享程序集,但这似乎并不容易,除此之外,我更喜欢更简单的解决方案。有人知道解决方法吗?
我可以只使用一个版本的 Dll 吗?
编辑:
我现在尝试了克里斯蒂安的建议:
D:\Develop\LEADTOOLS15\patch_maifest>mt.exe -inputresource:ltkrn15u.dll;#1 -out:old.manifest
Microsoft (R) Manifest Tool version 5.2.3790.2075
Copyright (c) Microsoft Corporation 2005.
All rights reserved.
mt.exe : general error c101008c: Failed to read the manifest from the resource of file "ltkrn15u.dll". Ressource not found.
如果我使用完整路径查看 dll 依赖项,我会看到以下内容:
替代文本 http://img340.imageshack.us/img340/4122/dependencywalk3.jpg< /a>
较低的 MSVCR80.DLL 是版本 ...42 的版本。我不明白这一点。为什么 MSVCP80.DLL 引用的 MSVCR80.DLL 版本与其他版本不同。这可能是 dependencywalker 的问题吗?
We include a 3rd Party lib+DLL that recently causes a lot of trouble on installations. Using dependencywalker, we found that the dll itself refers to two different Versions of
MSVCR80.DLL:
Version 8.0.50727.4053 and
Version 8.0.50727.42
alt text http://img101.imageshack.us/img101/1734/dependencywalk2.jpg
In MOST cases installation makes no problems, even if we distribute none of both versions. But in a number of cases our installation just does not start. We then find messages in the windows system event log from the SideBySide manger: "Version of DLL does not match". In most cases again this problem can be resolved, by installing the .NET framework (although we do not use this). But now we have a case where this does not help.
I know that a solution would be, to install both versions as a shared assembly, but that seems not to be easy, and besides that i would prefer a much simpler solution. Does anybody know a workaround?
Can i somehow use only one version of the Dll?
EDIT:
I now tried cristians advice:
D:\Develop\LEADTOOLS15\patch_maifest>mt.exe -inputresource:ltkrn15u.dll;#1 -out:old.manifest
Microsoft (R) Manifest Tool version 5.2.3790.2075
Copyright (c) Microsoft Corporation 2005.
All rights reserved.
mt.exe : general error c101008c: Failed to read the manifest from the resource of file "ltkrn15u.dll". Ressource not found.
If i view the dlls dependencies with full paths, i see the following:
alt text http://img340.imageshack.us/img340/4122/dependencywalk3.jpg
The lower MSVCR80.DLL is the one withe Version ...42. I dont understand this. Why does MSVCP80.DLL refer to a different Version of MSVCR80.DLL than the one besides it. Is that maybe a problem of the dependencywalker ?
发布评论
评论(2)
最好的选择是在应用程序安装程序包中提供所需的 DLL。至少使用您的第 3 方 DLL 所依赖的版本。
Microsoft 为其运行时 DLL (vcredits_*) 提供独立安装程序。可以下载 VisualStudio 2005 的最新版本 这里。这也是您的 DLL 链接的版本。您可以从安装程序中以静默方式启动可再发行软件包。
作为已安装系统的手动解决方法,只需在目标计算机上应用 redist 安装程序即可。
如果您选择此方法,则无需担心版本冲突,因为依赖于旧版本的应用程序将被重定向为始终使用最新版本。
为了更好地理解,您可以查看MSDN文章< /a>.
Your best option is to ship the needed DLLs within your applications installer package. Use at least the version that your 3rd party DLL depends on.
Microsoft offers standalone installers for its runtime DLLs (vcredits_*). The latest version for VisualStudio 2005 can be downloaded here. That is also the version that your DLL is linked against. You can silently launch the redistributable package from your installer.
As a manual workaround for already installed systems, simply apply the redist installer on the target machine.
If you choose this method, you don't need to be afraid of version conflicts, as applications depending on an older versions will be redirected to always use the most recent one.
For a better understanding you have look at this MSDN articles.
您必须从 dll 更改/更新清单资源。
mt.exe -inputresource:dll_with_manifest.dll;#1 -out:old.manifest
mt.exe -manifest new.manifest -outputresource:dll_with_manfiest.dll;#1
有时 RT_MANIFEST(类型 24)资源类型在资源表中没有 #1 索引,您应该使用 Resource查看器(ResourceHacker,或 ResEdit)并找出索引号。我见过清单索引号为 #2 的情况。
You have to change / update the manifest resource from the dlls.
mt.exe -inputresource:dll_with_manifest.dll;#1 -out:old.manifest
mt.exe -manifest new.manifest -outputresource:dll_with_manfiest.dll;#1
Sometimes the RT_MANIFEST (type 24) resource type doesn't have the #1 index in resource table, you should use a Resource Viewer (ResourceHacker, or ResEdit) and find out the index number. I have seen cases when the manifest has the #2 index number.