Login/Register
SidBySide: 3rd Party Dll refers to two versions of MSVCR80.DLL
Asked Answered
Solved c++windowsdllvisual-studio-2005side-by-side
P

2

2

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 ?

Pediculosis answered 13/10, 2009 at 10:52 Comment(1)
I'd really contact the 3rd party lib manufacturer and ask them to use only 1 of the versions! – Hydrolysis
W
1

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.

Wildon answered 13/10, 2009 at 11:46 Comment(4)
I now installed the redistributable file of Visual Studio 2005.This indeed solved he problem. I wonder that its useless to just copy the assembly directory into our \bin directory (containing all Dlls and EXEs) as we tried before. – Pediculosis
vcredist is the best option. I have seen one case when the vcredist package has failed to install. No clue why it didn't work, I had to manually unpack the vcredist.exe file and copy the files near our executable. – Pestalozzi
But why does coping the files near my executable NOT work, whereas after installing vcredist fixes the problem ? – Pediculosis
In my case I had only one version of CRT as dependency. With multiple versions it gets complicated. – Pestalozzi
P
1

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.

Pestalozzi answered 13/10, 2009 at 11:11 Comment(1)
I tried it - the dll seems to have no manifest. Please see the edits in my post. – Pediculosis
W
1

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.

Wildon answered 13/10, 2009 at 11:46 Comment(4)
I now installed the redistributable file of Visual Studio 2005.This indeed solved he problem. I wonder that its useless to just copy the assembly directory into our \bin directory (containing all Dlls and EXEs) as we tried before. – Pediculosis
vcredist is the best option. I have seen one case when the vcredist package has failed to install. No clue why it didn't work, I had to manually unpack the vcredist.exe file and copy the files near our executable. – Pestalozzi
But why does coping the files near my executable NOT work, whereas after installing vcredist fixes the problem ? – Pediculosis
In my case I had only one version of CRT as dependency. With multiple versions it gets complicated. – Pestalozzi

© 2022 - 2024 — McMap. All rights reserved.