Good day!

I am developing a little by little using visual studio (13), and I am constantly tormented by the Windows build feature, which is this: to work correctly on another computer, you need to handle the libraries that the application asks for output. At the same time, when the application is assembled in the release and launched, the studio automatically podkadyvaet the necessary libraries, so that the application could start.

What needs to be done in order for the studio to copy everything necessary for the library to a folder next to the ehe-shnik?

  • They actually lie there. Otherwise, it would not start from under the debugger. You look somewhere not there. - VladD
  • What libraries are we talking about - static or dynamic? Is there a DLL in the application itself? Is it written on .NET or not? - Vladimir Martyanov
  • I’m talking about dynamic libraries (dll), when viewed in the simplest case, we don’t include any external libraries in the project, however, to run correctly not from the compiler, a number of libraries must be put next to them, which I suspect contain plug-in headers. For qt, one good friend Avazart wrote dllcollector - a program that uploads the necessary dll files to the executable ehe-shnik. Surely there is something similar in the studio? - W_bear
  • If you are given an exhaustive answer, mark it as correct (a daw opposite the selected answer). - Nicolas Chabanovsky ♦

3 answers 3

Standardly, in the studio nothing like this is provided. It is assumed that the developer himself knows which libraries are used in his project and manages them himself.

However, there are libraries that can be implicitly linked, and the linking method (static / dynamic) can be configured in the project parameters:

  1. CRT is configured by the "C / C ++ \ Code Generation \ Runtime Library" parameter, by default dynamic linking is enabled and it is because of it that newbies have problems with software distribution; If you enable static linking, then the DLL will not need to be pulled.
  2. MFC - configured "General \ Use of MFC", not used by default
  3. ATL - configured "General \ Use of ATL", not used by default

The problem is that on the developer's machine all these libraries are installed along with the studio and therefore the software runs from any location. But on the user's machine, these libraries are often not there, from here the beginners have problems. The problem is solved either by static linking, or by installing the appropriate packages (redists) of the required versions (links are successfully located on the Microsoft website)

The second problem is that with automatic loading of a DLL, it is required that all libraries within the same binary link up the same way. This means, for example, that if QT links to CRT are dynamic, then our binary should link CRT dynamically. This can be bypassed if you use not automatic but manual loading of a DLL, but then the hemorrhag will grow many times. It's easier to slightly increase the installer in size, I can believe it.

    1. To work correctly on another computer, with the default build settings (that is, with the / MD key), you need to install Microsoft VC ++ Redistributable (2013, in this case), the correct architecture (x86 or amd64, depending on the build settings).
    2. Putting these files (msvcxxx120.dll) into the application folder is absolutely incorrect , because the mechanism of their correct registration in the system and updating is broken (On machines with Windows Update VC ++ redistributables enabled, they update themselves in the same folder as the old versions, including those with unresolved vulnerabilities )
    3. It is incorrect to distribute Debug-versions of these files (when building in Debug-configuration, with the / MDd key, versions of libraries with d at the end (msvcr120d.dll) are used, respectively, before distributing the application, make sure that the Release-configuration is enabled.
    4. For a simple application consisting of one exe file, dependencies on CRT libraries can be avoided by collecting the / MT key, which slightly increases the application size, but with a complex application consisting of multiple libraries, each library will increase in size and is lost.
    5. When using third-party libraries / frameworks (Qt, boost, etc.), you should make sure that their libraries are compiled exactly according to the application configuration - an application compiled with / MD when trying to use Qt compiled with / MT and vice versa (and Also, if a third-party library is built with another version of CRT, for example, msvcr90.dll, it is almost guaranteed to cause errors
      1. It was helped by specifying in the project properties / MT (/ MTd):
        Properties -> Configuration Properties -> C / C ++ -> All Options -> Runtime Library -> Multi-threaded (/ MT) (or Multi-threaded Debug (/ MTd))
      2. as well as specifying the Windows XP platform:
        Properties -> Configuration Properties -> General -> Platform Toolset -> Visual Studio 2013 - Windows XP (v120_xp)