after a half a year of using VS2010 i switched back to VS2008, cause i found VS2010 mostly unusable. It’s much slower, unstable, compiling and linking is slower, the new data format of Class viewer and browser information is big shit, runtime has errors or unforseeable effects… and so on.

Now that i had this manifest hell again, i found out a easy solution for that problem. I know, it’s looking horrable, but its the most efficent way to overcome this ERROR, that Mircosoft made:

Edit the crtassem.h in C:\Program Files\Microsoft Visual Studio 9.0\VC\include directory to always define _BIND_TO_CURRENT_VCLIBS_VERSION.

Like this:

#if !defined(_BIND_TO_CURRENT_VCLIBS_VERSION)
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1
#endif

or change the original

#ifndef _CRT_ASSEMBLY_VERSION
#if _BIND_TO_CURRENT_CRT_VERSION
#define _CRT_ASSEMBLY_VERSION “9.0.30729.1″
#else
#define _CRT_ASSEMBLY_VERSION “9.0.21022.8″
#endif
#endif

to

#ifndef _CRT_ASSEMBLY_VERSION
#if _BIND_TO_CURRENT_CRT_VERSION
#define _CRT_ASSEMBLY_VERSION “9.0.30729.1″
#else
#define _CRT_ASSEMBLY_VERSION “9.0.30729.1″
#endif
#endif

Theres one more thing:

If you really have a manifest problem and guessing why, just let windows trace the loading of the application with

sxstrace Trace -logfile:log.bin

start your program, then

sxstrace Stoptrace

and convert the logfile to human readable format with

sxstrace Parse -logfile:log.bin -outfile:log.txt

With this, your can see a protocol of loaded and found sxs-dlls, manifests and so on. Very interesting…

Good luck!

thanks for that very helpful advice. I spend day and days investigating that matter… without a solution.

Your my hero!

Greetings,

Dirk

_BIND_TO_CURRENT_VCLIBS_VERSION tip worked for me.

Setting version=”9.0.21022.8″ worked perfectly for me.

Thanks for the useful article. The described technique work also fine for deploying of debug versions, by working with corresponding debug folders and manifest files:
(Microsoft.VC90.DebugCRT, Microsoft.VC90.DebugCRT.manifest, etc.)
Currently I work on a VS2008 solution that contain 4 executables and 18 dlls, and deploying debugs is a practical (for Testers, PMs, etc. purposes).

And further, even the Common Control Dll (comctl32.dll) can be deployed locally, skipping the WinSxS. This can be done with the following steps:

1. Create a folder “Microsoft.Windows.Common-Controls” in deployment exe folder, for example
MyApp\exe\Microsoft.Windows.Common-Controls

2. copy comctl32.dll file from C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a folder
into MyApp/exe/Microsoft.Windows.Common-Controls folder

3. copy x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a.Manifest file from C:\WINDOWS\WinSxS\Manifests folder
into MyApp/exe/Microsoft.Windows.Common-Controls folder

4. rename x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a.Manifest to Microsoft.Windows.Common-Controls.Manifest

5. remove publicKeyToken from this new manifest (Microsoft.Windows.Common-Controls.Manifest)

6. in all dlls and exes manifests remove publicKeyToken from the section described “Microsoft.Windows.Common-Controls”.

Now comctl32.dll is deployed locally, and WinSxS is bypassed.

Best regards,
Svetoslav Kyuchukov

Eurorisksystems Ltd.
Varna, BG