c++ - you - visual studio release configuration missing
How do you pack a visual studio c++ project for release? (6)
I'm wondering how to make a release build that includes all necessary dll files into the .exe so the program can be run on a non-development machine without it having to install the microsoft redistributable on the target machine.
Without doing this you get the error message that the application configuration is not correct and to reinstall.
- Choose Project -> Properties
- Select Configuration -> General
- In the box for how you should link MFC, choose to statically link it.
- Choose Linker -> Input. Under Additional Dependencies, add any libraries you need your app to statically link in.
Be aware that Microsoft do not recommend that you static link the runtime into your project, as this prevents it from being serviced by windows update to fix critical security bugs. There are also potential problems if you are passing memory between your main .exe and .dll files as if each of these static links the runtime you can end up with malloc/free mismatch problems.
You can include the DLLs with the executable, without compiling them into the .exe and without running the redist tool - this is what I do and it seems to work fine.
The only fly in the ointment is that you need to include the files twice if you're distributing for a wide range of Windows versions - newer OSs need the files in manifest-defined directories, and older ones want all the files in the program directory.
You need to set the run-time library (Under C/C++ -> Code Generation) for ALL projects to static linkage, which correlates to the following default building configurations:
- Multithreaded Debug/Release
- Singlethreaded Debug/Release
As opposed to the "DLL" versions of those libraries.
Even if you do that, depending on the libraries you're using, you might have to install a Merge Module/framework/etc. It depends on whether static LIB versions of your dependencies are available.
You shouldn't link directly against the DLL. Instead, link against the corresponding import library (should be
Wininet.lib). The DLL still needs to be accessible to your application at runtime, of course. The
.lib file is needed by the linker to setup proper linkage to the DLL.
Am I correctly doing what I think is statically linking function calls and the dll?
What you're doing is usually called dynamic linkage (more or less dynamic ..), but its (afaik) the only way to go for Windows System APIs. 'Static' linkage would embed the Wininet code directly into your executable, with no need for an external DLL.
Statically linked application - invalid or corrupt dll
"Static Linking" is the process of including the code in your application. By nature, a DLL is a dynamic link library and therefore no, including the DLL in the directory of your application is not static linking - it remains dynamic. The reason for placing it in the directory of the application is so that the application can find it without the need for install.
I don't suppose it is the DLL that is "corrupt" - I suspect you are attempting to static link the DLL into the application which cannot happen. You need instead to include the correct .lib file, whatever that is, in the additional libraries to link with and ensure that the lib file you link with is not the DLL exports package for wininet.dll
VS2010: Link in a single library statically
Answering my own question here:
All you need to do to statically link a library in VS is:
1) Add the .lib file to the list found in properties -> linker -> input : Additional Dependencies.
2) Add the directory that the .lib file is located at to the properties -> linker -> general : Additional Library Directories.
If the .lib file is a statically linked library, then that is all you have to do.
The main reason I was confused was that a .lib file could also be a companion file alongside a dll, and not a static library itself.