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

谁说胖子不能爱 提交于 2019-11-28 03:27:55
Susam Pal

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

user5058117

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!