Home/ Questions/Q 426689
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T19:30:16+00:00

We include a 3rd Party lib+DLL that recently causes a lot of trouble on

  • 0

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 ?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0