Dynamic and static linking and deployment in Visual Studio 2010

Question

I've an unmanaged C++ project in Visual Studio 2010. It uses boost, glut and another library from a vendor.

I've set up the project to create a more "dll-indepenendent" executable possible. All the boost libraries are linked statically and there is no need of dll in the directory where the executable stays.

Same thing for the Glut, I've linked the static glut32.lib instead of the glut32.dll and again no problem.

I've selected for the Runtime libraries the NON-dll version, i.e. Multithreaded Debug (for Debug configuration) and Multithreaded for Release configuration.

Now, the vendor I was speaking before, provides two alternatives a Vendor.lib and a Vendor.dll.

The Vendor.lib is added in the Linker->Additional dependencies but at runtime I always have to put the Vendor.dll in the same directory of the executable, otherwise the runtime environment complains because it doesn't find the Vendor.dll library.

How should I solve this issue? I would like to avoid to put in every directory the .dll file.

I don't want to put the dll in the same directory of the exe and in general what are the guidelines to deploy unmanaged c++ console applications in Visual Studio?

I know there are many questions and pages about this argument but none of those clarified me this point.

Some idea?

Answer 1

Microsoft is a bit funny in the way it handles this: when you create a .dll, you also create a .lib, which contains the public symbols in the .dll. You must link against the .lib in order to load the .dll at runtime, but this .lib is still not a static library. If your vendor provides a version for static linking, there will either be no .dll, or two .lib (presumably in different directories or with different names). Just another example of Microsoft making serious development more difficult than necessary.

Answer 2

The Vendor.lib needs to be a statically-compiled library. If when you link this you still need Vendor.dll, it sounds like Vendor.lib is actually an import library rather than a static library.

Check to see if the vendor provides another Vendor.lib (which should be a good bit larger than your current .lib) which is a static library and try linking to that. If so, you won't need the dll.