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

7

42

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

  1. Downloaded vcredist_x86.exe from http://www.microsoft.com/download/en/details.aspx?id=3387
  2. 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

  1. Downloaded vcredist_x86.exe from http://www.microsoft.com/download/en/details.aspx?id=5638
  2. 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.

  1. 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.
  2. 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.

  1. 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).
  2. 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.

  1. 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

Langland answered 18/1, 2012 at 16:19 Comment(3)
You can tell from the version numbers. Your dev machine has revision 6195 but the redist versions you used are very old: 42 and 762. There were several security patches since SP1. Easiest way is to just create a Setup project.Immaterialism
This is probably what you are looking for.Shilohshim
The easiest way to figure the redist version required for my build was to check the manifest file created by Visual Studio while building the project. Mine was located at Mine was located at C:\Foo\Release\Foo.exe.intermediate.manifest. I have elaborated it in my answer to my own question below.Langland
L
52

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.

Langland answered 19/1, 2012 at 10:44 Comment(2)
Thank you so much for this! Three years later, and you solved my exact issue!Talmud
you can also get the dll version from the xstrace.exe tool, as explained hereManor
W
4

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

Weizmann answered 17/5, 2012 at 14:38 Comment(1)
Thank you for your response. This question has already been answered 5 months ago.Langland
M
4

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

Measure answered 21/11, 2012 at 18:37 Comment(1)
That's a very good point. Thank you for sharing this. Now, I have added a note about processor architecture in my answer to this question.Langland
O
3

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.

Overexpose answered 17/10, 2012 at 9:3 Comment(1)
Nope, as I said, I had "Two development XP machines with VS2005 installed". Exactly the same VS2005 on Each.Overexpose
R
3

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.

Regality answered 30/10, 2012 at 7:35 Comment(0)
D
0

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

Doggoned answered 3/6, 2014 at 19:3 Comment(0)
D
-2

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.

Dagda answered 28/6, 2015 at 13:0 Comment(1)
Could you add some line breaks? It is almost impossible to read that.Norvell

© 2022 - 2024 — McMap. All rights reserved.