I am trying to recreate an existing C Win32 DLL with a single, simple function. I have managed to do this using VS C++ 2008 Express, and my new DLL works on my Vista dev machine, and on the client's XP machine. However, it doesn't work on other sites. I have checked dependencies and my DLL requires MSVCR90D.dll and KERNEL32.dll, where the original DLL only requires KERNEL32.dll.
What is MSVCR90D.dll, and how do I create a simple Win32 DLL without this dependency?
The D at the end of MSVCR90D.dll shows that you compiled your .exe in debug mode. You should only distribute your application in release mode.
You can make sure they have everything they need by having them install the Microsoft Visual C++ 2008 Redistributable Package x86 or x64. Otherwise you can probably simply copy the files they need for them by finding them on your computer (check first at %systemroot%\system32)
Please see this MSDN link.
Check if your client's machine has the 2008 runtime installed on his system or not. If not you can either get it installed on his/her system or statically compile the runtime with your application.
Link with the static version of the C runtime library. The setting is under "Code generation" in the project properties. Then you won't need to worry about the MSVCR* DLLs at all.
The 'D' in the name means debug. This is a clear indicator of Visual Studio's Debug build. Use the Release build, and all will be well.
If the target system doesn't have the C runtime yet, you should generally use the official installer to put it there. Some of the versions of the runtime you might want to know about are these:
You can also develop a complete installation package that includes the redistributable DLLs (but never a debug DLL) needed by your application and handles the installation of side by side (SxS) assemblies into the system assembly cache correctly, using a technique known as merge modules. This approach is easier if you have the full installation of Visual Studio (not the free VS Express edition) but the resulting installation packages still may not handle installation of the runtime on older (such as Win 2K or 9x) platforms well at all.
The MSDN article Redistributing Visual C++ Files describes what the rules are, and how to comply with them as easily as possible. It provides a starting point to learn more about many issues related to deployment.
If the original DLL whose functionality you are replacing did not have a reference to MSVCR90.DLL, then it must have been statically linked to the runtime. You probably should check on the assumptions of the intended application that will be calling your DLL. Mixing C runtime libraries in a single process is not always easy. If the hosting application is already using MSVCR90.DLL, then you really should too. This is a larger issue than fits in an answer to the specific question at hand, however, so I'd encourage you to research it and ask new questions as needed.
Another approach to avoiding the installation of the later runtime DLLs is to link to MSVCRT.DLL, which is distributed with modern versions of windows as a system component. This is the runtime that was shipped with Visual C 6.0, lightly updated for critical issues and kept current to match the OS. It isn't available for 64-bit builds at all, and it is quite difficult to trick Visual Studio into using it in place of the newer runtime.
Likely what you want to do is build a Release version of your DLL, test it, and distribute that instead of the Debug build that you're distributing now.
However, it is possible to make a Debug DLL that depends on MSVCR90.DLL, the non-debug version of that DLL. To do this (VS 2008 SP1, instructions are similar for other VS):
You'll have to recompile everything, but you should now be linking against the non-debug VS DLLs.