VC Software Release Story (1)

When we excitedly send our own small program to friends, or formally release the product to the user's hands, often encountered "because the application is not configured properly, the application failed to start, reinstall the application may correct this problem."

Such a hint is really a little discouraged ah, then how to solve it, what caused the problem?

(Note that this article does not involve msvc7.x, because this version of the two main products I touch very little)

First of all, statically linking all libraries is not a problem, but not all cases we can statically link all libraries, especially when there is an MFC extension DLL, and when using a third-party library without static lib (these libraries may require dynamic link msvcrt).

MSVC6 ERA does not have this problem, because the program can not run will prompt the lack of xxx.dll, it is easy to solve, just need to put the necessary DLLs and software to publish together (this need to pay attention to DLL author's redistribution license agreement).

MSVC8,MSVC9 introduced the so-called Assembly concept (note that not. NET that meaning of the Assembly, but with this concept) using WinSxS to avoid DLL hell, but (well, everyone is afraid of this but) introduced another problem: version matching.

Assume the following scenario:

1 Our build environment is MSVC8 or MSVC9, and always installs the latest patches

2 published to the user compiled binary and MSVC8/MSVC8SP1/MSVC9/MSVC9SP1 redist

3 Failed to run

This is really frustrating, why not? The root of the problem in menifest, if we open binary with the menifest, and check the version number of the relevant DLL, will find the version number is much higher than msvc redist inside, which will cause the system to refuse to load the DLL, surface phenomenon is

"Reinstalling the application may correct the problem because the application is not configured correctly and the application fails to start."

Conclusion: Patching of the compiled environment will upgrade the header file of the compilation environment, resulting in a more advanced version number for binary requirements compiled by default configuration.

Workaround:

MSVC8: Defines the _use_rtm_version macro, which forces the compilation of Bingary using the Msvc8 RTM version number.

MSVC9: Cancels the definition of the _bind_to_current_vclibs_version macro, which compiles bingary using the MSVC9 RTM version number.

This way, the standard MSVC8/MSVC8SP1/MSVC9/MSVC9SP1 redist can be used.

Msvc10 Microsoft canceled the previous design, back to the practice of MSVC6, so the correct release should be the following

Static Link: This is the least compatible problem, but you can't enjoy the security and improvements that the system patches bring.

Dynamic Link: Can rely on the system directory of the MSVCRT DLL, so the system patching will automatically enjoy the system updates brought about by the improvements. You can also put MSVCRT and your binary together so that you will not be able to enjoy the system updates.

Note: There are a handful of users who report that even copying files such as Msvcrt100.dll to the system directory or binary directory does not work, and I cannot reproduce it, and I do not know the specific reason.

VC Software Release Story (1)