Make your VS2008-compiled program "copy and run"

We know that the new side-by-side mechanism can help solving the famous "dll hell" problem, but also make it hard to copy your program and run as VC6 does, a really good and simple way. Besides, if your program consists of several dlls, or even 3rd party ones, some tricks are needed to achieve this goal.

Recently, since some bugs only happened on some of the product machine, and our software consists of 80-90 dlls, both native and managed ones. It is really a headache to analyze. Some experimental codes are needed incrementally and wish to see develop build (even a debug build) ASAP without generating a fresh installation package, so, make our local build copy-and-run on product machine would be great.

Below is simple description for my case.

1: Remove all dependent dlls' embedded manifest info.


For 3rd party ones, manual removal is necessary.You can use ResHack.exe to do that. Open the file, locate the manifest part, remove or change it, then save and recompile.

For your own dlls, you can turn off the embedded manifest generation in VS2008. If a bunch of projects are involved, one external propertysheet can be shared by all projects, then simple switching can help you achieve that. Property-sheet can be added manually in "Project Property-General-Inherited Project property Sheets" or "View-Property Manager".

2: Keep the manifest header in executable. It seems that the executable file without manifest header could not loaded.

3: Copy the dependent dlls and manifest files to your target folder.
VS runtime packages can be found under "C:\Windows\winsxs", including both manifest files(under "Manifest" sub-folder) and binaries. Don't forgot to locate correct version and also maybe the debug binaries.

4: It is easy for us to miss some files, and that would be troublesome to locate them. Windbg can be used to load the executable, watching the loading log, then generally it would be obvious to tell which file causes the trouble. Furthermore the "sxstrace" tool can also help you generate the side-by-side loading log (google it, and it seems that windows xp does not have it).

Finally, a few hours were spent to make our product's debug build copy-and-run on the develop machine, then using windbg or VS2008's remoting debugging, it just worked as a develop machine.