The newest Visual Studio (VS2005 and next version Orcas) by default will link all C/C++ applications you create with the IDE wizard to the latest CRT library which is msvcr80.dll. By default, again, it uses a shared library link (dll must be present in the system path on the target).
Only XPe FP2007 brings in the library but as a part of the huge .Net 2.0 Framework component. It is not even wrapped into a separate primitive component. Obviously, you don't want to add such beast as .Net 2.0 to just add msvcr80, unless you need .Net 2.0 in your image.
Here is a few tricks you can use to get rid of possible problems with missing msvcr80 at runtime:
- Copy msvcr80.dll along with msvcm80.dll and msvcp80.dll libraries from VS2005 folders on PC where you run the VS tools (typically somewhere under "\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT").
- Make sure you are working with the proper version of the libraries corresponding to the project settings - Debug or Release. Often, people are working with Debug build (which is default by the wizard, btw) that requires debug version of the msvcr80 - msvcr80d.dll.
- Please copy manifest built along with your application exe in VS2005. This will make sure it will use the right dependencies versions.
- Often (depends on your application logic and implementation) you can simply use only basic Win32 API and you may not need the CRT libraries at all. The MSVCR80 may get linked however if you have "Multi-Threaded DLL (/MD)" or "Multi-Threaded Debug DLL (/MDd)" option set for the Runtime Library on the Code Generation tab in the C/C++ branch of the Project Properties in VS2005. Just use the single-threaded Dlls there and disable Exceptions. Or, alternatively and my favorite, just link statically to the library to remove the dependency at all (use "Multi-Threaded (/MT)" option for instance).
- Make sure to include side-by-side components in TD.
- If the above doesn't help, install VS2005 (x86) Redist package at runtime.
- If the application still fails to load, run the application through DependencyWalker on the target devices. More precisely, run it through Profiler of the DependencyWalker. Then you should be able to see why it's failing to load.