Why installing vcredist_x86.exe doesn't fix SideBySide error when I develop an EXE on one machine and run it on another one? - c++

Issue
I wrote a C++ project called 'Foo' using Microsoft Visual Studio 2005 Verison 8.0.50727.762 (SP.050727-7600) on Windows XP Professional Version 2002 Service Pack 3. I built the project into Foo.exe. Then, I copied the file Foo.exe to a Windows Server 2003 Enterprise Edition Service Pack 2. When I tried to run it, it failed with this error,
C:\foo.exe
The application has failed to start because the application configuration is incorrect.
Reinstalling the application may fix the problem.
In Event Viewer > System, three events were logged.
Event ID: 32; Source: SideBySide
Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was
The referenced assembly is not installed on your system.
Event ID: 59; Source: SideBySide
Resolve Partial Assembly failed for Microsoft.VC80.CRT.
Reference error message: The referenced assembly is not installed on your system.
Event ID: 59; Source: SideBySide
Generate Activation Context failed for C:\foo\Foo.exe.
Reference error message: The referenced assembly is not installed on your system.
Installing Microsoft Visual C++ 2005 Redistributable didn't fix it
Downloaded vcredist_x86.exe from http://www.microsoft.com/download/en/details.aspx?id=3387
Installed it. The installer created a folder called C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd.
The version of this software as found from 'Add or Remove Programs' was '8.0.50727.42'.
On trying to run C:\foo\foo.exe, I got the same errors I described above.
Installing Microsoft Visual C++ 2005 SP1 Redistributable didn't fix it
Downloaded vcredist_x86.exe from http://www.microsoft.com/download/en/details.aspx?id=5638
Installed it. The installer created a folder called: C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700.
The version of this software as found from 'Add or Remove Programs' was '8.0.56336'.
On trying to run C:\foo\foo.exe, I got the same errors I described above.
Copying CRT DLLs and manifest from the same machine (where I'm running the EXE) didn't fix it.
I copied msvcm80.dll, msvcp80.dll and msvcr80.dll from
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd
to C:\foo.
Next, I copied
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd.manifest
to C:\foo and renamed it to Microsoft.VC80.CRT.manifest.
The fourth line of the manifest file looked like this:
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.42"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
When I tried running C:\foo\foo.exe this time, it didn't work. I repeated this thing again with the DLLs in C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700 and the corresponding manifest file. It didn't help as well. I got the same error.
In both cases, I got the following errors in Event Viewer > System.
Event ID: 34; Source: SideBySide
Component identity found in manifest does not match the identity of the component requested
Event ID: 58; Source: SideBySide
Syntax error in manifest or policy file "C:\foo\Microsoft.VC80.CRT.MANIFEST" on line 4.
Event ID: 59; Source: SideBySide
Generate Activation Context failed for C:\foo\Foo.exe. Reference error message: The manifest file contains one or more syntax errors.
Copying CRT DLLs and manifest from the Windows XP machine (where I built the EXE) didn't fix it.
I copied msvcm80.dll, msvcp80.dll and msvcr80.dll from
C:\winnt\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700 of Windows XP machine (where I developed and built foo.exe)
to C:\foo of Windows Server 2003 (where I am trying to run foo.exe).
Next, I copied
C:\winnt\winsxs\Manifests\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700.manifest
to C:\foo and renamed it to Microsoft.VC80.CRT.manifest.
The fourth line of the manifest file looked like this:
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
On trying to run C:\foo\foo.exe now I got the same errors mentioned in the previous section.
Copying CRT DLLs and manifest from Visual Studio folder fixed it.
Copied msvcm80.dll, msvcp80.dll, msvcr80.dll and Microsoft.VC80.CRT.manifest from C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT of Windows XP machine (where I developed and built foo.exe) to C:\foo of Windows Server 2003 machine (where I am trying to run it).
The fourth line of the manifest file looked like this:
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.6195"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
This time I could run C:\foo\foo.exe without any issues.
Question
I was expecting that installing 'Microsoft Visual C++ 2005 SP1 Redistributable' (vcredist_x86.exe) as described in the second approach would fix it. But it didn't. Copying the DLLs and manifest files from the C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT folder of the development machine fixed it. Why was it so?
Build options
In case, it helps you to answer my question. Here is the compiler and linker options I picked up from Visual Studio project properties:
Configuration properties > C/C++ > Command Line:
/O2 /GL /D "_MBCS" /FD /EHsc /MD /Fo"Release\\" /Fd"Release\vc80.pdb" /W3 /nologo /c /Wp64 /Zi /TP /errorReport:prompt
Configuration properties > Linker > Command Line:
/OUT:"C:\MixedBag\Release\Foo.exe" /NOLOGO /MANIFEST /MANIFESTFILE:"Release\Foo.exe.intermediate.manifest" /DEBUG /PDB:"c:\MixedBag\release\Foo.pdb" /OPT:REF /OPT:ICF /LTCG /MACHINE:X86 /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

I'll answer my own question. Comments to the question by Hans Passant and Luke helped.
I downloaded Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update and installed it on the system where I was trying to run C:\foo\foo.exe. The EXE ran fine after this.
The installer placed the CRT DLLs in C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86. So, yes, 8.0.50727.6195 was the version of the CRT DLLs I was looking for as Hans Passant rightly said.
The easiest way to figure this version was by looking at the manifest file generated by Visual Studio while building my project on the development system. Mine was located at C:\Foo\Release\Foo.exe.intermediate.manifest. It had a tag like this:
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.6195'
processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
So, this is a clue that I needed 8.0.50727.6195 version of the DLLs. The rest was a matter of searching for the right vcredist_x86.exe which happened to be in the URL I have mentioned in the second paragraph. The page in that URL contains a link to KB2538242 which shows the version numbers of the DLLs that would be installed by the installer.
Note: As Elie has mentioned in a different answer to this question, since this is a 32-bit application, it is necessary to install vcredist_x86.exe (not vcredist_x64.exe) on the system where this application is supposed to be run irrespective of whether that system is a 32-bit Windows system or a 64-bit Windows system. Once again, the .manifest file provides this clue in the processorArchitecture attribute.

You have to install "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update" which is here: http://www.microsoft.com/en-us/download/details.aspx?id=26347

Here is how you fix this issue:
You WILL STILL Get the sidebyside errors If the application being used is 32 bit and you try running it on a 64 bit OS which has the VC_REDISTx64 installed.
Simple solution, you MUST ALSO LOAD THE VC_REDISTx86 on the 64 bit os

I had a somewhat related problem. Two development XP machines with VS2005 installed, call them A and B. I developed, built and ran on A. Then I copied the whole project to B. Built there. Tried to run and got the same error messages mentioned by SusamPal. I realized that on B's WinSxS there were the x86_Microsoft.VC80.CRT_xxx manifests (and folders) but not the corresponding x86_Microsoft.VC80.DebugCRT_xxx ones (and why?!). I tried several of the dances and incantations described by SusamPal to no avail. I solved the problem by copying the appropriate folders from the WinSxS of A to B AND the appropriate manifests from the WinSxs\Manifests.

Although my application was
developed on Win 2k8 R2 x64 with vs2008 (which has msvcm90.dll, msvcp90.dll and msvcr90.dll in C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\redist\amd64\Microsoft.VC90.CRT)
and ran on win 2k3 SP2 x64,
but the msvcm80.dll, msvcp80.dll and msvcr80.dll are needed.
After install Microsoft Visual C++ 2005 SP1 Redistributable Package (x86), the application can be installed and ran rightly.

For me the side by side error went just by chabging the under the setting c/c++ ->CodeGeneration->RuntimeLibrary ,make it MTD that is multi-Thread Debug

We have really following problem here: the application executable references dlls using manifest machinery. In the deep past application authors just copied required dll's into system directories. Unfortunately this caused so called "dll hell" problem when overwriting older dll versions by incompatible newer one could make applications stop working. MS then came up with with versioning idea (winsxs).
Unfortunately this is quite complex machinery and it is definitely not a good idea to try manually installing dlls (assemblies) into the sxs folder. Installing so called "redistributable packages" is not a perfect solution either.
Additionally, this cannot help when we want debug versions. As MS prohibits distribution of debug versions of supporting dlls, "redistributable packages" won't install them. (Note that the assembly id depends on current subversion of VS2005 and is related to installed supporting libraries.)
Usually, the VS installer adds the required assemblies to the system, but after some time installation of updates or newer SDK's and tools may damage this correct state.
Let's assume we have this situation - our debug libraries are no longer integrated into system. Suppose we have given workspace with project A and active debug configuration giving not working application. We can then create installer project, say C in current workspace, add our application (or strictly, project with active configuration) to it. Setup installer project to put our executable in some place (desktop is the right place regarding this situation) enable dependencies check and some other minor properties. Then build project C and run installer (or "install" from VS using context menu). Now your application and other created with debug dll libraries start to work.
Beware when you run installer with "remove" option you came to previous situation. Here is good article related to distribution topic: http://blogs.msdn.com/b/vcblog/archive/2007/10/12/how-to-redistribute-the-visual-c-libraries-with-your-application.aspx.
If you have some other applications and want to deploy them simply by copying, maybe on non development machine without installed VS, you may create dummy project together with appropriate configuration and installer for it . You then install it once on each machine and then copy executable(s) you are working on.

Related

GCC suddenly stopped working? Missing dependencies? [duplicate]

I have a problem with our executable. I'm running this C++ 32-bit executable on my Windows 7 64-bit development box that also has all those Microsoft applications (Visual Studio 2008 + 2010, TFS, SDK, Microsoft Office)...
And it's still running just fine.
Now I got the client installation of the very same program and was asked to test it with a clean Windows 7 installation. Thus I got one Windows 7 64-bit VMware and updated it to Windows 7 SP 1 (the very same version my developer box is tuning).
But while on my developer box everything is fine the program does not work with the VMware (30 days trial) box.
The x86 Dependency Walker is telling me that the following DLL files are missing:
API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
GPSVC.DLL
IESHIMS.DLL
I googled for those API-MS-WIN-... DLL files and found they should actually already be part of Windows 7 (some sites claiming the belong to Windows 8 and Windows Server 2012 though).
I already tried the suggested fixes I found, which are:
running 'sfc /scannow'
installing Visual Studio 2008 SP1 runtime executables
But that didn't solve anything. :-(
Side note: My development box does not have them either, and does not seem to need them. For example, the user32.dll on my box does not link against one of those, while the installation on the VMware does.
Any idea on how to fix this issue?
I tried to find a suitable download / fix on the Microsoft pages, but I failed.
After solving my issue I wanted to report what I found out, and I can't post this as an answer because the question has been closed.
Actually all the DLL files reported missing by the Dependency Walker tool, namely those
* API-MS-WIN-CORE-...
type DLL files were not part of the actual problem.
In my case the registration of three OCX files was missing and after that everything was just fine, BUT Dependency Walker tool still listed all the very same DLL files as before even when the program was just running fine now.
The gist of it: As someone elsewhere stated, the tool is a bit dated by now and does not always work properly with a newer OS. Thus keep an eye open and don't get mislead by missing 'API-MS-WIN-CORE-COM-L1-1-0.DLL', ... the problem probably lies entirely elsewhere.
This problem is related to missing the Visual Studio "redistributable package." It is not obvious which one is missing based on the dependency walk, but I would try the one that corresponds with your compiler version first and see if things run properly:
Visual Studio 2015
Visual Studio 2013
Visual Studio 2010
Visual Studio 2008
I ran into this problem because I am using the Visual Studio compilers, but not the full Visual Studio environment.
Going to dare to inject a new link here: The latest supported Visual C++ downloads. Stein Åsmul, 29.11.2018.
I just resolved the same problem with C++ Qt 5 and Windows 7 64 bits with MSCVC 2012.
In the beginning I thought it was a MSVC/Windows DLL file problem, but as BorisP said, the problem was in my project dependencies. The key is "How to know your project dependencies in Qt 5?".
As I didn't find any clear way to know it (Dependency Walker didn't help me a lot...), I followed next the "inverse procedure" that takes no more than 5 minutes and avoid a lot of headaches with DLL file dependencies:
Compile your project and take the executable file to an empty folder: myproject.exe
Try to execute it, It will retrieve an error (missing DLL files...).
Now, copy all the DLL files from Qt (in my case they were in C:\Qt\Qt5.1.1\5.1.1\msvc2012_64_opengl\bin) to this folder.
Try to execute again, it will probably works fine.
Start to delete progressively and try every time your executable still works, trying to leave the minimum necessary DLL files.
When you have all the DLL files in the same folder it is easier to find which of them are not valid (XML, WebKit, ... whatever..), and consequently this method doesn't take more than five minutes.
I just resolved the same problem.
Dependency Walker is misleading in this case and caused me to lose time. So, the list of "missing" DLL files from the first post is not helpful, and you can probably ignore it.
The solution is to find which references your project is calling and check if they are really installed on the server.
#Ben Brammer, it is not important which three .ocx files are missing, because they are missing only for Leo T Abraham's project. Your project probably calls other DLL files.
In my case, it was not three .ocx files, but missing MySQL connector DLL file. After installing of MySQL Connector for .NET on server, the problem disappeared.
So, in short, the solution is: check if all your project references are there.
As mentioned, DCOMP is part of the VC++ redistributables (implementing the OpenMP runtime) and is the only truly missing component. All the rest are false reports.
Specifically API-MS-WIN-XXXX.DLL are API-sets - essentially, an extra level of call indirection introduced gradually since Windows 7. Dependency Walker development seemingly halted long before that, and it can't handle API sets properly.
So there is nothing to worry about there. You're not missing anything more.
A better alternative to find the truly needed DLL files that are missing (if that is indeed the problem) is to run Process Monitor and step backwards from the failure, searching for sequences of failed probes for a specific DLL file in all the system path.
I also ran into this problem, but the solution that seems to be a common thread here, and I saw elsewhere on the web, is "[re]install the redistributable package". However, for me that does not work, as the problem arose when running the installer for our product (which installs the redistributable package) to test our shiny new Visual Studio 2015 builds.
The issue came up because the DLL files listed are not located in the Visual Studio install path (for example, C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist) and thus had not been added to the install. These api-ms-win-* dlls get installed to a Windows 10 SDK install path as part of the Visual Studio 2015 install (e.g. C:\Program Files (x86)\Windows Kits\10\Redist).
Installing on Windows 10 worked fine, but installing on Windows 7 required adding these DLL files to our product install. For more information, see Update for Universal C Runtime in Windows which describes the addition of these dependencies caused by Visual Studio 2015 and provides downloads for various Windows platforms; also see Introducing the Universal CRT which describes the redesign of the CRT libraries. Of particular interest is item 6 under the section titled Distributing Software that uses the Universal CRT:
Updated September 11, 2015: App-local deployment of the Universal CRT is supported. To obtain the binaries for app-local deployment, install the Windows Software Development Kit (SDK) for Windows 10. The binaries will be installed to C:\Program Files (x86)\Windows Kits\10\Redist\ucrt. You will need to copy all of the DLLs with your app (note that the set of DLL files are necessary is different on different versions of Windows, so you must include all of the DLL files in order for your program to run on all supported versions of Windows).
This contribution does not really answer the initial question, but taking into account the hit-rate of this thread I assume that there are quite a few people dealing with the problem that API-MS-WIN-CORE- libraries cannot be found.
I was able to solve a problem where my application refused to start with the error message that API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL is not found by simply updating Visual Studio.
I don't think that my build environment (Windows 7 Pro SP1, Visual Studio Ultimate 2012) was messed up completely, it worked fine for most of my projects. But under some very specific circumstances I got the error message (see below).
After updating Visual Studio 11 from the initial CD-Version (I forgot to look up the version number) to version 11.0.61030.00 Update 4 also the broken project was running again.
This solved the issue for me:
Uninstall the Visual Studio 2010 redistributable package if you have it installed already, and then install Microsoft Windows 7 SDK.
I solved the problem. When I registered the OCX files, I ran it with the Command Window that had been executed as an administrator.
For anybody who came here, but with a Photoshop problem: my solution was to uninstall the MS VC++ redistributable first x86 and 64 both. Then install one appropriate to the Windows version and architecture (86 or 64).
Installation of SQL Server Management Studio 2014 on a freshly installed Windows 7 resolved this problem at our client after a two-day ridiculous battle.
I came here with this problem occurring, after trying a fresh Windows 7 OEM install, upgrading to Windows 10.
After some searching of Microsoft forums and such I found the following solution which worked for me:
Replace C:\Windows10Upgrade\wimgapi.dll with the one from C:\Windows\System32\wimgapi.dll
I suggest also checking how much memory is currently being used.
It turns out that the inability to find these DLL files was the first symptom exhibited when trying to run a program (either run or debug) in Visual Studio.
After over a half hour with much head scratching, searching the web, running Process Monitor, and Task Manager, and depends, a completely different program that had been running since the beginning of time reported that "memory is low; try stopping some programs" or some such. After killing Firefox, Thunderbird, Process Monitor, and depends, everything worked again.
I had the same problem. After spending hours searching on the web, I found a solution for me.
I copied the file combase.dll file (C:\Windows\System32) to the release folder, and it resolved the problem.
Just to confirm answers here, my resolution was to copy the DLL that was not loading AND the ocx file that accompanied it to the system32 folder, that resolved my issue.

The program can't start because mfc120ud.dll is missing from your computer

I'm trying to run an application that I've recently developped onto another computer and which I've compiled using VS2013.
Running it I get:
The program can't start because mfc120ud.dll is missing from your computer. Try reinstalling the program to fix this problem.
I've searched the mfc120ud.dll from the net but without any result. I've copied/pasted this dll file from the computer on which I've developed that app onto the system32 of the other computer, doing that implies:
C:\Users\u\System32\mfc120ud.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support.
Knowing that the computer on which I'm developing is a 64-bits one and the other one is 32-bits, and that I've copied/pasted the mfc120ud.dll version from System32, how do I to fix this issue?
The program can't start because mfc120ud.dll is missing from your computer. Try reinstalling the program to fix this problem.
That is one of the debug libraries for MFC. That's the library that you link against when you build debug releases of your program. It is present on your developer machine, but you cannot redistribute it.
You need to do the following:
Build your project for release. This will link against the release versions of any runtime DLLs.
Install the MSVC and MFC redistributable dependencies on any machine on which you plan to run your program. An alternative is to install the runtime DLLs in the same directory as your executable.
I've copied/pasted the mfc120ud.dll version from System32
You are not allowed to do that. Retrace your steps and undo that.
Check if you've accidentally defined _DEBUG in your preprocessor definitions.
I once had the same error when I copy pasted settings from the debug build.
For me, I build the project using VS2013 xp mode. Then deployed on window XP system. Then I got error that mfc120ud.dll is missing.
I installed vcredist.exe for vs2013, which fixed the issue.
I am able to run my MFC app.
When I encountered a similar problem, first installed the VS 2013 C++ redistributables vcredist_x86.exe and vcredist_x64.exe (https://support.microsoft.com/en-us/help/3138367/update-for-visual-c-2013-and-visual-c-redistributable-package), then I determined what dependencies the file had:
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin>dumpbin.exe /dependents "C:\Temp\MyLibrary.dll"
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file C:\Temp\MyLibrary.dll
File Type: DLL
Image has the following dependencies:
mfc120d.dll
MSVCR120D.dll
KERNEL32.dll
USER32.dll
OLEAUT32.dll
mscoree.dll
Image has the following delay load dependencies:
MyLibraryCoreD.dll
Summary
5000 .data
2000 .nep
1000 .pdata
4E000 .rdata
1000 .reloc
1000 .rsrc
10000 .text
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin>
Next I searched the registry and it did not find mfc120d.dll, only mfc120.dll and mfc120u.dll (see https://serverfault.com/questions/576831/how-do-i-know-if-a-dll-is-registered), so instead of using the debug version I switched to the release version which uses mfc120.dll and the application worked.

run vs2005 c++ project in later version of visual studio

I have a C++/CLI project that was created in VS2005. I'm hoping to run this in VS2010 (or 2012) as that is my main IDE and I need to modify some things in the C++/CLI project as well and its irritating to have to switch back and forth to vs2005 to recompile, copy etc.
The other important reason is my projects running in VS2010/2012 are in .NET4 so there is no option to move everything on to VS2005.
The project has dependencies on unmanaged third party libraries that themselves have dependencies on the debug versions of the c++ redistributable libraries (msvcr80.dll, msvcm80.dll, msvcp80.dll)
When I first ran the upgraded project I received 'specified module could not be found' -
It was then I noticed the cli project is being compiled against the later versions of msvc (msvcr90.dll)
cli assembly dependencies as per depends; vs2005 on left vs 2008 on right
Is there any way to make a later version of VS compile using the 2005 libraries?
update its not vital which one it compiles against (and may not be possible anyway) but is it possible to run and debug both side by side?
When I try to run the compiled project I get this error message:
I've tried copying the manifest file from the vs2005 project to the vs2010 project but this does not work (same error message). I also disabled the embedded manifest and replaced the generated .manifest file with the one from vs2005 and this does not work either.
update2 I've got past this error by specifying the msvcr libraries in the manifest:
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
however now when I run my application one of the third party libraries throws an AccessViolationException - Attempted to read or write protected memory when I try to use one of the methods. This code otherwise works fine in vs2005.
I have since discovered Daffodil for Visual Studio which does exactly what I need, namely compile against vc80 in visual studio 2010. After installation the Platform Toolset dropdown gets a few more options:
nb, you still need to have the relevant version of Visual Studio installed, eg if targeting vc80 you need vs2005.
nb2, Intellisense is broken in vs2010 for cli/c++ which is a major letdown after the amount of time researching getting the project to work on vs2010
From http://www.davidlenihan.com/2007/07/winsxs.html
"So how does an application know what version of a DLL it needs to load? That is where a "manifest" comes into play. A manifest is an XML file that contains information used to create the directory in C:\Windows\winsxs so that a particular DLL can be loaded."
Have you considered making a manifest for the application? I mean, the error message says that the problem is that the manifest is lacking, so perhaps it will be sufficient to create a manifest (either through the project settings) or adding a hand written one?
See: Problem loading RT without Manifest

DLL dependency not found when debugging with Visual Studio 11 RC

My project is a standalone C++ application that uses FMOD for playing sound. I've previously developed the same project with Visual Studio 2010 without any problems, but 2012 gives me the classic error: "The program can't start because fmodex.dll is missing from your computer. Try reinstalling the program to fix this problem." The project seems to load other DLLs(such as Direct3d related files and d3d shader compiler) just fine.
The problem occurs only if trying to debug or run the program from the IDE, not if I copy the executable to the appropriate directory with DLL and run it manually. If I remove all references to FMOD from the program, the debugging and running works fine. I've made sure that I have correct working directory in Project settings (besides it loads all the other files just fine in the same directory). I originally converted the project from Visual Studio 2010, but tried to create a new project from scratch with no luck. I've also tinkered all the possible compiler and linker settings through, and googling doesn't seem to help either.
I'm guessing that the problem has something to do with the new Metro style apps and it's way to handle external dependecies, but I have also turned "Metro Style App Support" off. I'm starting to think I've really tried everything I can and have no idea what to try next. Directions for getting more diagnostic information would be much appreciated as well! Thanks!
Edit: Visual Studio version I'm using is Visual Studio Ultimate 2012 RC, Version 11.0.50706.0 QRELRC July, 2012
Go to the project's properties:
Configuration Properties | Debugging | Environment
And add the following item:
PATH=c:\path\where\the\dll-is;$(Path)
My sympathies, I live in DLL hell a lot lately it seems. Two suggestions:
You can drive the IDE from the command line with devenv which has a /useenv switch.
"... Use PATH, INCLUDE, LIBPATH, and LIB environment variables instead of IDE paths for VC++ builds.
dumpbin /dependents [*.exe] [*.dll] will show you DLL dependencies.
dumpbin /dependents openssl.exe
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file openssl.exe
File Type: EXECUTABLE IMAGE
Image has the following dependencies:
SSLEAY32.dll
LIBEAY32.dll
WSOCK32.dll
MSVCR80.dll
KERNEL32.dll
Summary
4000 .data
14000 .rdata
1000 .rsrc
33000 .text
It may be that VS is running the app with a different current directory to when you run the app by hand.
VS typically sets the current directory to the project folder, which is usually not the same as the folder where the built binaries are. When you run it by hand you're probably running it from the latter, not the former.
If that is the problem then the code that loads fmodex.dll must be depending on the current dir being in the DLL search path, which can a big security risk (lookup "DLL planting" or DLL "pre-loading") and which is actively blocked by some Windows configurations.

VC++ CRT Redist problem

I've developed a 64 bit dll using C++ and Visual Studio 2008 and i'm trying to register it on a target machine using 'regsvr32.exe'. I've checked the manifest file and it clearly states what version of CRT is needed:
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='amd64' publicKeyToken='1fc8b3b9a1e18e3b' />
When i try to register the file i always get a side-by-side error message stating that the application settings are incorrect and that i should reinstall it.
Log Error: Generate Activation Context
failed... Reference error message: The
referenced assembly is not installed
on your system.
The target machine runs Windows Xp Professional 64 bit. I've tried to install the corresponding VC++ redistributable package( VC++ 2008 Redist x86 and x64 ), create a setup and include the corresponding merge module ( microsoft_vc90_crt_x86_x64.msm ), install all VC++ redistributable packages etc. No matter what's installed it will always fail.
If i check for the dependent files and they are correctly located inside the WinSxS folder, but if i run Dependency Walker on the file it will complain too that the files from the VC9 CRT could not be found.
If i build the file for 32 bit it will correctly register on a 32 bit OS. I'm running out of ideas so any help is very appreciated.
Thanks,
Adrian.
EDIT *This is reproductible only on Win XP 64, all works fine on Windows 7 64 bit.
I'm no expert in installers but have you thought about distributing the redistributable's in the root folder of your application?
As for me, I've never heard of using regsvr32.exe to install crt redist's.
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT' ...
shouldn't it be
<assemblyIdentity type='win64' name='Microsoft.VC90.CRT' ...
?
You need the 64-bit runtime
It sounds like despite the app is 64 bit it's looking for the 32bit crt dlls. Did you try to install the 32bit redistributable package?
Here is a good description on how to track down SideBySide failures:
http://blogs.msdn.com/b/junfeng/archive/2006/04/14/576314.aspx
In the end I've managed to fix this by including a newer version of C++ redistributable merge modules into the setup along with all the required policy merge modules in order to redirect the calls to any old version to the new one that's available.
Most important thing here is that the exe redistributable include the policy files and the merge modules don't so they need to be separately added.