Alright, after doing a ton of research and trying almost every managed CPP Redist I can find as well as trying to copy my DLLs locally to the executing directory of the app
I had a similar problem the first time I deployed a VS 2005 app on a target machine -- had to bring over the MSVCRT80 DLL. Are you saying you already have the 2008 VS runtime library there?
ETA: Also, dumb question, but are you sure you have both the CRT Runtime (linked to above) and the .NET Runtime, with the same version you compiled against (probably 3.5)? You probably already know this (especially considering your score) but they're 2 different things.
I found a solution that seems to work although I don't like it very much.
I had to copy the folders:
Microsoft.VC90.CRT & Microsoft.VC90.MFC
From: Program Files\Microsoft Visual Studio 9.0\VC\redist\x86
Into the deployed application directory, I just can't figure out why this seems to work and the redistributables did nothing.
EDIT: Looking at the manifest I probably don't need to copy the MFC directory
Typically I've found that the pragma comment style manifest decleration's to be much more error free, from a developer maintenence and an over all build action perspective. The XML manifest's are natoriously snafu.
The fimiluarity with how the linker operates and the usual compilation of C code and the fact that you simply tak this in, onto one of your source files, keeps everything a bit feeling more "together";
#pragma comment(linker, \
"\"/manifestdependency:type='Win32' "\
"name='Microsoft.Windows.Common-Controls' "\
"version='6.0.0.0' "\
"processorArchitecture='*' "\
"publicKeyToken='6595b64144ccf1df' "\
"language='*'\"")
Did you deploy the CRT libraries on the target machine? Long shot: since you have a dependency on 32-bit code, you should set Target Platform in the Build property tab to x86.
EDIT: trouble-shoot side-by-side resolving problems with the Sxstrace.exe utility, available on Vista.
Best way to solve this problem is to download process monitor which is free from: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Add a filter to watch only your process and it will show you all file access the process tries. This will show you exactly which dll it can't find.
I always use this when faced with the same problem - if only microsoft filled in the filename in the thrown exception it would all be easier.