Dynamic and static linking and deployment in Visual Studio 2010

Question

I have an unmanaged C ++ project in Visual Studio 2010. It uses boost, glut and another library from the provider.

I created a project to create a more "dll-independencelydent" executable. All acceleration libraries are linked statically and there is no need for a dll in the directory where the executable remains.

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

I chose the version of NON-dll for runtime libraries, that is, multi-threaded debugging (for debugging configuration) and a configuration with several messages for release.

Now the provider I mentioned earlier provides two alternatives to Vendor.lib and Vendor.dll.

Vendor.lib is added in the Linker-> Additional dependencies, but at runtime I always need to put the Vendor.dll file in the same directory of the executable file, otherwise the runtime complains because it does not find a provider. dll libraries.

How do I solve this problem? I would like not to put a DLL file in every directory.

I do not want to put the DLL in the same exe directory and what are the general guidelines for deploying C ++ unmanaged console applications in Visual Studio?

I know that there are many questions and pages about this argument, but none of them clarified this point to me.

Some idea?

Answer 1

Microsoft is a little ridiculous in how it deals with this: when you create a .dll, you also create a .lib that contains the public characters in the .dll. You must set the link to .lib to load the DLL. runtime, but this .lib is still not a static library. If your provider provides a version for static linking, there will be either a .dll or two .libs (presumably in different directories or with different names). Another example of how Microsoft is making serious development more difficult than necessary.

Answer 2

Vendor.lib must be a statically compiled library. If, when linking this, you still need Vendor.dll, it looks like Vendor.lib is actually an import library, not a static library.

Check to see if the provider has provided a different Vendor.lib (which should be larger than your current .lib), which is a static library and is trying to link to this. If so, you will not need a dll.