James_Clements
asked on
DLL's cannot be found - maybe something to do with Manifest Files?
My company makes a program that makes calls to components that are provided to us from a variety of other developers. One set of dll components are not able to be found. I mean that when we make the call, it errors saying that it can't find the dll that we are trying to access. We know that dll's should normally be found if the path to that file is located in the PATH Environment variable but these dll's are not following that rule for some reason. The component developers suggested that we needed to put the location of these files as the very first entry of the PATH environment variable but that doesn't work either. We only have success when we copy all the dll's to the same directory as our application.
We don't really know what manifest files are for but we were provided with 2 manifest files with these components. Could these somehow be key? I'll paste the contents of those files as seen in notepad here:
File 1:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microso
<noInheritable></noInherit
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.4053" processorArchitecture="x86
<file name="msvcr80.dll" hash="0a38b652c9d03caab803
<file name="msvcp80.dll" hash="678bf3da5d1987bb88fd
<file name="msvcm80.dll" hash="34f57d3d73b2810fa7b5
</assembly>
File 2:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microso
<noInheritable></noInherit
<assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50727.4053" processorArchitecture="x86
<file name="mfc80.dll" hash="46fc9af0bb795fec574d
<file name="mfc80u.dll" hash="1d3d4e3c0689295a042c
<file name="mfcm80.dll" hash="118a4fdbd7fe8cbc8988
<file name="mfcm80u.dll" hash="72caf15a421e57ad2bcf
</assembly>
We don't really know what manifest files are for but we were provided with 2 manifest files with these components. Could these somehow be key? I'll paste the contents of those files as seen in notepad here:
File 1:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microso
<noInheritable></noInherit
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.4053" processorArchitecture="x86
<file name="msvcr80.dll" hash="0a38b652c9d03caab803
<file name="msvcp80.dll" hash="678bf3da5d1987bb88fd
<file name="msvcm80.dll" hash="34f57d3d73b2810fa7b5
</assembly>
File 2:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microso
<noInheritable></noInherit
<assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50727.4053" processorArchitecture="x86
<file name="mfc80.dll" hash="46fc9af0bb795fec574d
<file name="mfc80u.dll" hash="1d3d4e3c0689295a042c
<file name="mfcm80.dll" hash="118a4fdbd7fe8cbc8988
<file name="mfcm80u.dll" hash="72caf15a421e57ad2bcf
</assembly>
Hello James
Back in Window 98 days Dynamic Link Libraries (DLLs) were a headache. Teh whole idea of having a library of resources, such as icons, bitmap images, menu data, dialog boxes, and all the text strings used in them, was so that repeatedly used functions could be "called" from within the DLL to memory for as long as needed and then removed when finished. In Windows there are "shared DLLs" that save developers from having to write their own Open, Save As, Print, and loads of other commonly used dialogs, routines, and functions. In Windows 98 there were frequent clashes between multiple versions of DLL files existing in known "paths. To try and avoid this many installer packages would place their own copies of the shared DLL(s) in the program directory so that it/they would be found first when a function in a named DLL was called. Unfortunately Win98 suffered from a flaw where the DLL functions were not released from memory when the need for them concluded, and there were still version conflicts when another program called the same DLL.
Windows XP adopted a pretty good way of separating the various versions of the same DLL by placing them in separate sub-folders of a the folder C:\Windows\WinSxS (SxS = Side-by-Side Assemblies) and making them uniquely identifiable using Manifests. The oldest (and usually the originally installed DLL) remains in the system folder and newer versions are added to new SxS folders.
What is a Manifest:
http://www.samlogic.net/articles/manifest.htm
For your information, your two DLLs and corresponding Manifest files refer to 32-bit (x86) components used to make up the "Visual C++ Runtime Library version 8" and the corresponding "Microsoft Foundation Classes (MFC)":
msvcr80.dll = Microsoft.VC80.CRT version 8.0.50727.4053
mfc80.dll = Microsoft.VC80.MFC version 8.0.50727.4053
"Runtime" support is there so that applications written that programming language (Visual C++ in this case) and using that particular version of the language (version 8 in this case) can use common functions and calls without requiring the developers of the application to rewrite them all themselves.
So, while developers should really be harnessing consistent and recommended methods instead of suggesting things like making theirs the first "path" statement, if the application works with the DLLs in the program folder and that doesn't crash other applications, then just leave it like that.
It's not ideal with DLLs such as the two you are talking about, because they would normally come as a "redistributable" installer inside a Windows Installer package for the application, and would be installed if the support was not already in place. For example, software that can be installed on anything from Windows 2000 to Windows 7 may or may not use the redistributable runtimes dependent on the operating system the software is installed on at the time.
Type "microsoft visual c runtime redistributable" into a google search and take a look at the plethora of results ranging from 2005 to 2010 redistributables. From what I can see, the version "8.0.50727.4053" DLLs should be in the Visual C++ 2005 Redistributable which has an SP1 security update:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647
Hope this helps
Bill
Back in Window 98 days Dynamic Link Libraries (DLLs) were a headache. Teh whole idea of having a library of resources, such as icons, bitmap images, menu data, dialog boxes, and all the text strings used in them, was so that repeatedly used functions could be "called" from within the DLL to memory for as long as needed and then removed when finished. In Windows there are "shared DLLs" that save developers from having to write their own Open, Save As, Print, and loads of other commonly used dialogs, routines, and functions. In Windows 98 there were frequent clashes between multiple versions of DLL files existing in known "paths. To try and avoid this many installer packages would place their own copies of the shared DLL(s) in the program directory so that it/they would be found first when a function in a named DLL was called. Unfortunately Win98 suffered from a flaw where the DLL functions were not released from memory when the need for them concluded, and there were still version conflicts when another program called the same DLL.
Windows XP adopted a pretty good way of separating the various versions of the same DLL by placing them in separate sub-folders of a the folder C:\Windows\WinSxS (SxS = Side-by-Side Assemblies) and making them uniquely identifiable using Manifests. The oldest (and usually the originally installed DLL) remains in the system folder and newer versions are added to new SxS folders.
What is a Manifest:
http://www.samlogic.net/articles/manifest.htm
For your information, your two DLLs and corresponding Manifest files refer to 32-bit (x86) components used to make up the "Visual C++ Runtime Library version 8" and the corresponding "Microsoft Foundation Classes (MFC)":
msvcr80.dll = Microsoft.VC80.CRT version 8.0.50727.4053
mfc80.dll = Microsoft.VC80.MFC version 8.0.50727.4053
"Runtime" support is there so that applications written that programming language (Visual C++ in this case) and using that particular version of the language (version 8 in this case) can use common functions and calls without requiring the developers of the application to rewrite them all themselves.
So, while developers should really be harnessing consistent and recommended methods instead of suggesting things like making theirs the first "path" statement, if the application works with the DLLs in the program folder and that doesn't crash other applications, then just leave it like that.
It's not ideal with DLLs such as the two you are talking about, because they would normally come as a "redistributable" installer inside a Windows Installer package for the application, and would be installed if the support was not already in place. For example, software that can be installed on anything from Windows 2000 to Windows 7 may or may not use the redistributable runtimes dependent on the operating system the software is installed on at the time.
Type "microsoft visual c runtime redistributable" into a google search and take a look at the plethora of results ranging from 2005 to 2010 redistributables. From what I can see, the version "8.0.50727.4053" DLLs should be in the Visual C++ 2005 Redistributable which has an SP1 security update:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647
Hope this helps
Bill
ASKER
Bill, thanks for your well thought out response. Are you suggesting that in cases where the dll's cannot be found, it may be possible to install this redistributable for the visual c runtime and then it would work? I'll give that a try.
What you two don't probably realize about our software is that another party writes software normally to call our software. In those cases, we would have to tell them to copy/paste the dll's from our installation folder to their executable folder which is really not a pleasant way to do things.
What you two don't probably realize about our software is that another party writes software normally to call our software. In those cases, we would have to tell them to copy/paste the dll's from our installation folder to their executable folder which is really not a pleasant way to do things.
Hi James
It is possible that installing the Visual C++ Runtime Distributable 2005 MIGHT solve an issue like this, seeing as the two referenced DLLs are part of that package, but you have ended up in a strange situation with the 3rd-party applications.
Generally if software is to be installed that requires and expects a particular runtime version to be in place, the installer package should test for the presence of the runtimes and either install the missing components from within its own package or via a download before continuing.
I am not a programmer, however, so anything beyond knowing what is supposed to happen takes me into unfamiliar territory. So making educated guesses as to the best way of circumventing your DLL issues is not something I would be comfortable doing.
I found a couple of pages that go fairly in-depth on the subject of "Side by Side Assemblies". Perhaps they, or "related" links within them, might explain things better than I tried to or suggest a workaround for your situation:
http://en.wikipedia.org/wiki/Side-by-side_assembly
http://msdn.microsoft.com/en-us/library/aa376307(v=vs.85).aspx
Bill
It is possible that installing the Visual C++ Runtime Distributable 2005 MIGHT solve an issue like this, seeing as the two referenced DLLs are part of that package, but you have ended up in a strange situation with the 3rd-party applications.
Generally if software is to be installed that requires and expects a particular runtime version to be in place, the installer package should test for the presence of the runtimes and either install the missing components from within its own package or via a download before continuing.
I am not a programmer, however, so anything beyond knowing what is supposed to happen takes me into unfamiliar territory. So making educated guesses as to the best way of circumventing your DLL issues is not something I would be comfortable doing.
I found a couple of pages that go fairly in-depth on the subject of "Side by Side Assemblies". Perhaps they, or "related" links within them, might explain things better than I tried to or suggest a workaround for your situation:
http://en.wikipedia.org/wiki/Side-by-side_assembly
http://msdn.microsoft.com/en-us/library/aa376307(v=vs.85).aspx
Bill
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Accepted own solution becuase other solutions had failed and ours worked.
And what is wrong with that?
See http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx on the order in which DLLs are searched for.
Note the section on Standard Search Order.