在 VS2015 中构建会出现 SideBySide 错误

Question

I have an x86 C++ app that works in VS2013 and I'm upgrading to VS2015. The build and link work fine but when I run I get an error:

Unable to start program. This application has failed to start because the application configuration is incorrect. Review the manifest file for possible errors. Reinstalling the application may fix this problem. For more details, please see the application event log.

The application event log shows:

Activation context generation failed for "MyApp.exe". Dependent Assembly Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762" could not be found. Please use sxstrace.exe for detailed diagnosis.

So I ran sxstrace and got:

=================
Begin Activation Context Generation.
Input Parameter:
    Flags = 0
    ProcessorArchitecture = Wow32
    CultureFallBacks = en-US;en
    ManifestPath = MyApp.exe
    AssemblyDirectory = MyApp\Debug\
    Application Config File = 
-----------------
INFO: Parsing Manifest File MyApp.exe.
    INFO: Manifest Definition Identity is (null).
    INFO: Reference: Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762"
INFO: Resolving reference Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762".
    INFO: Resolving reference for ProcessorArchitecture WOW64.
        INFO: Resolving reference for culture Neutral.
            INFO: Applying Binding Policy.
                INFO: No publisher policy found.
                INFO: No binding policy redirect found.
            INFO: Begin assembly probing.
                INFO: Did not find the assembly in WinSxS.
                INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC80.DebugCRT\8.0.50727.762__1fc8b3b9a1e18e3b\Microsoft.VC80.DebugCRT.DLL.
                INFO: Did not find manifest for culture Neutral.
            INFO: End assembly probing.
    INFO: Resolving reference for ProcessorArchitecture x86.
        INFO: Resolving reference for culture Neutral.
            INFO: Applying Binding Policy.
                INFO: No publisher policy found.
                INFO: No binding policy redirect found.
            INFO: Begin assembly probing.
                INFO: Did not find the assembly in WinSxS.
                INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC80.DebugCRT\8.0.50727.762__1fc8b3b9a1e18e3b\Microsoft.VC80.DebugCRT.DLL.
                INFO: Attempt to probe manifest at MyApp\Debug\Microsoft.VC80.DebugCRT.DLL.
                INFO: Attempt to probe manifest at MyApp\Debug\Microsoft.VC80.DebugCRT.MANIFEST.
                INFO: Attempt to probe manifest at MyApp\Debug\Microsoft.VC80.DebugCRT\Microsoft.VC80.DebugCRT.DLL.
                INFO: Attempt to probe manifest at MyApp\Debug\Microsoft.VC80.DebugCRT\Microsoft.VC80.DebugCRT.MANIFEST.
                INFO: Did not find manifest for culture Neutral.
            INFO: End assembly probing.
    ERROR: Cannot resolve reference Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762".
ERROR: Activation Context generation failed.
End Activation Context Generation.

I'm not sure how this helps and I still don't understand why I'm getting this error if I built the app from scratch in VS2015. I've tried installing Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) which corresponds to the version 8.0.50727.762 but it hasn't helped.

A lot of the older posts on this subject (eg Why installing vcredist_x86.exe doesn't fix SideBySide error when I develop an EXE on one machine and run it on another one? ) mention checking the.manifest file generated by the build but I can't find one. Does VS2015 no longer generate them?

Answer 1

One of your used library is build against the Debug Runtime of Vs2005 (Microsoft.VC80. Debug CRT). Those debug files are NOT part of the normal Visual C++ 2005 SP1 Redistributable Package.

Do a trial & error search to figure out which library and get the release version which uses the release Dlls which are part of the Redistributable Package.

Answer 2

What type of 3d party libraries are you using and how are they being linked? For example are you using DLLs, Libs or both? If you are using statically linked 3rd party libraries, then they must be compiled and built using the same version of VS you are using with the same code generation flags. You may also want to visit the developer's websites of those libraries and look to see if they have a newer version and one that is already compiled with your current version of VS. If they only have 2010, 12 or 13 they should work but you will have to open them in 2015 and build them out yourself

For example; I use libpng, openal, ogg-vorbis, glm & others, For all of the 3rd party libraries that my applications depend on I have created a file directory where they are stored and I created environment variables on my main machine for an easier linking process. For all of these libraries except for glm since glm is a headers only library I had to create different environment variables for each version of visual studio I'm using; for example OGG-Vorbis are 2 different libraries used for doing audio; so I would have OGG_SDK_2010, VORBIS_SDK_2010... OGG_SDK_2015, VORBIS_SDK_2015 where these libraries being the newest version from their websites are loaded and built out in both release & debug versions of each version of Visual Studio that I may be using.

Before I redid my pc I did have VS2008, 2010, 2012, 2013 and 2015; now that I reinstalled my OS I currently only have VS2013 & 2015. So any of my older programs from VS2008, VS2010 & VS2012 I will have to first port them to 2013 and fix any dependencies and take care of any deprecation. Once that process is completed I'll then be able to port them over to 2015.

Now, from my experience on porting one of my programs over to 2015 from 2013 there was a little bit of a process that had to be done, however, I do not recall off of the top of my head exactly what had to be done. I do know that it did take a little bit of time reading different threads and trial and error to get everything to work properly.

It may also be that you could be using a library that has not been updated and that there is currently no more work or support being done for it that the library dependency that you may have may be considered deprecated in itself and if that is the case, then you may have to do some research to find an alternative library that will fit your needs. Once you find the appropriately library, then it is a matter of stripping out all of the old method calls and replacing them with the equivalent calls to the newer library. However in some cases this may involve a complete rewrite of your existing program.

For example; I use OpenGL and when I first started to learn it I was using version 1.0 where everything that was used to do render calls was all done on the CPU. Now that I'm using Modern OpenGL and using GLSL Shaders on the GPU and have successfully created a 3D Graphics Shader Rendering Engine; the transition from OpenGL 1.0 to 4.5 was quite a bit to take in and the difference between the two versions of the same Library or API by OpenGL was a challenge. Porting from an older version of a compiler to a newer version is sometimes fairly easy like porting from 2012 to 2013, there wasn't that much of an overhead change, but sometimes porting from an old version to a newer version can be tedious such as going from 2005 to 2015.

Also do not forget to check these 3rd party libraries props files to make sure they are pointing to the correct version of VS.

Answer 3

@magicandre1981's answer is correct but didn't give any clues how to help track it down. I eventually noticed that when Visual Studio links my app it prints out:

glew32sd.lib(glew.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'glew32sd.lib(glew.obj)' or at 'MyApp\Debug\vc80.pdb'; linking object as if no debug info

I rebuilt glew32sd.lib from the glew source code and my problem was fixed.