"Application configuration is incorrect, program cannot start" solution (vc2008 SP1)

First of all, thank the several bloggers:

Http://hi.baidu.com/fairysky/blog/item/130dda13db7b050a5aaf53be.html

Http://hi.baidu.com/fairysky/blog/item/e7a8366dbaa735f3431694c8.html

Http://www.cppblog.com/lf426/archive/2008/04/12/46885.aspx

Time Reason:

have time to organize again: a bit messy, sorry.

Thanks for the xcyber reply:

Why is it so frustrating.
In this way, Microsoft invented manifest is wrong, because everyone is worried about the runtime, really not as VC6, this is possible.
It's very simple, open your VS, create a setup project under Setup and development, then add the merge Module, select the runtime you want, and then build, and the resulting file will be published with your program.

Resources

1, VS2005 solve the "application configuration is not correct, the program can not start" problem

2. VS2005 installation File "Application failed to start because the application is not configured correctly"

3. Deployment issues for Microsoft Visual C + + 2008 release Programs

4, VC program can not be written on other machines to run the solution

Add (First look at the above 4 link, after you encounter a problem, look at a few links below.

5, about VS2008 SP1 C + + generated manifest in the runtime version number of the issue ( recommended 1)

6. In vc++2008 projects, how to display the version of the C + + library to be used. ( recommended 2)

7. VC9 SP1 generates manifests with the wrong version number

PS: Some people think it's a bug and report it to Ms website, but "recommendation 1" thinks it's not a bug

8, VC Runtime Binding ... (MS's official blog explains the problem)

About VC Runtime Bindings (Chinese translation of the link above)

9, Deployment (C + +) ( recommended, more ugly to understand )

A few more useful links to link 9:

Assembly Search Order ( English ), mainly about the CRT, MFC and other DLLs and manifest file deployment methods

Select a Deployment method

Use Program Files\Microsoft the files provided in the visual Studio 8\vc\redist directory to install specific Visual C + + assemblies as private assemblies for your application. This method is recommended for users who do not have administrator rights to install an application or to run an application by sharing it. For an example, see how to: Deploy using Xcopy. (Excerpt: Select Deployment method)

summarized as follows:

There are 2 deployment methods for programs developed using vs2008/vs2008: Shared parallel assemblies and private assembly deployment methods

The so-called shared parallel assembly deployment Method refers to a program-dependent CRT, MFC, ATL DLLs, and manifest files located in the C:\windows\winsxs directory on the target machine. When you publish a program, you only need to copy the program to the target machine; private assembly deployment Method refers to the time when the program is published, where the CRT, MFC, ATL DLLs that are dependent are placed in the current directory of the program

for release Programs

An easy way to compare is to deploy with shared assemblies, install Vcredist.exe (Microsoft Visual C + + 2008 SP1 Redistributable Package (x86)

You can also use the deployment method of the private assembly of the following debug program

for the Debug version program

If the target machine is installed with the VS development environment (VS2005 sp1/vs2008 SP1), a shared parallel assembly is also installed on the machine, containing versions of the DLLs (version 8.0, 9.0, located under the C:\Windows\Winsxs directory), no deployment is required , just copy the program that needs to be published to the target machine, which is the same as the release version of the program.

On a machine that does not have the VS development environment installed (VS2005 sp1/vs2008 SP1), it can only be deployed as a private assembly (because Vcredist.exe installs only the release version of the CRT, MFC, ATL DLLs, and manifest files , no corresponding version of Debug)

There are 2 known methods: ( for VS2008 SP1 , there will be two versions of CRT, MFC, ATL DLLs: 9.0.21022.8 and 9.0.30729.1 on the system after SP1 is installed

1. Make the version number of the dependencies in the manifest file of the current program consistent with the version of the DLL under the Redist directory in the VC installation directory, both 9.0.30729.1

Method:

A, a symbolic _bind_to_current_vclibs_version is defined when the project is compiled, defined in C:\Program Files\Microsoft Visual Studio 9.0\vc\include\ crtassem.h file (assuming VC installed in C disk), so that the compiled program manifest rely on the CRT version 9.0.30729.1 (Similarly, for MFC should also define a similar symbol, you can own in the VC include directory Search " 9.0.30729.1 "or" 9.0.21022.8 ", you can find the corresponding header file that defines the symbol.

b, modify the manifest file in the generated EXE or DLL through external tools (as if the Mt.exe in the Windows SDK can do it, but there is very little information about the tool)

2, the VC installation directory under the Redist directory (C:\Program Files\Microsoft Visual Studio 9.0\vc\redist) Microsoft.VC90.CRT Copy to the current directory of the program to be published, modify the Microsoft.VC90.CRT directory The version number in the Microsoft.VC90.CRT.manifest file is changed to 9.0.21022.8, which causes the program to mistakenly assume that the DLL version of VC in the directory is 9.0.21022.8 (essentially still 9.0.30729.1)

Description:

1, Link 4 is wrong, according to my own experiments, if the use of private assembly deployment method, you must ensure that the manifest file version number are equal, there is no program to be published in the manifest file version number is greater than or equal to dependencies (CRT, MFC, ATL DLL) version number of the argument

2, the use of shared parallel assembly deployment of the program, will automatically be based on the so-called "policy" (located in the C:\WINDOWS\WinSxS\Policies directory) to jump (from the low version number to the high version number jump) such as the version number of the manifest in the program is 9.0.21022.8, and in fact the program is compiled with VC2008 SP1 (version number is 9.0.30729.1), when the program actually executes, it will be based on

X86_policy.9.0.microsoft.v