I have a enterprise c++ application that I'd like to ship out and I do use the dbghelp library to get a stacktrace if my application crashes. What is the best practice for doing this?
My target users are windows10 and according to this page, I should be okay to ship out the dbghelp.dll along with it?
"The redistribution policies for these included DLLs were specifically designed to make it as easy as possible for people to include these files in their own packages and releases."
Related
Is there a preferred canonical way to distribute development packages (for example a DLL and headers) to developers (without source) on windows?
Coming from a Linux background my preference is split a project into three packages:
A runtime - e.g. libfoo-1.2.3.rpm containing /opt/foo/lib/libbar.so -> /opt/foo/lib/libbar.so.1.2.3
A development package - e.g. libfoo-devel.1.2.3.rpm containing /opt/foo/include/bar.h
A source package - e.g. libfoo.1.2.3-src.tgz containing the source and build machinery
I expect few windows developers would complain if given a zip file with a similar directory layout.
E.g.
foo-devel.zip:
foo/doc/foobar.pdf
foo/include/bar.h
foo/lib/libbar.dll
foo/lib/libbar.lib
for completeness only (off-topic) the run-time might be:
foo-runtime.zip:
foo/doc
foo/lib/libbar.dll
or:
foo-runtime.msi
- install libbar.dll to an appropriate location
However I am still curious if there is actually a preferred way of doing it?
For example should you provide a foo-devel.msi to be installed on the build machine?
I am not interested in the question what should go into the library.
Anyone who is can see for example Distributing (native C++) libraries on windows
It still is worth bearing in mind ABI compatibility issues if providing a C++ interface rather than only a C one.
Another related question is Is there a best practices guide to distributing native C libraries for Windows?. That question covers the what but this one asks how.
The canonical (to an extent) way of distributing redistributable files on Windows is Windows Installer Merge Module (msm). It is intended to be integrated into another Windows Installer (msi) package. DLL should go there as they are files needed at runtime.
As for development files (e.g. headers, libraries, etc), there is no standard way of organizing them in the file system on Windows. Therefore, it could be a simple archive or an msi package. For an msi package, it makes sense to not require an admin account to install it.
How do I deal with this situation where the user's machine may not have dll like msvcp100.dll, msvcp100.dll? I don't want to my software not install on user's machine because this kind of error. I've been thinking in either find a tool and copy every single needed dll to the executable file run or try build a static version of Qt (may have sort of same result, in the end). I've seen applications that doesn't provide those dlls and it's up to user to get them, install etc. It may be a issue for those users, finding the right dll matching version and all. I'd like to avoid it.
How is this usually solved in a real world application?
You redistribute them in your installer.
Deployment of Qt apps is an uneasy issue. One should understand that you need to redistribute a compiler's dlls, as well as Qt dlls. For the msvc 2010 compiler you may just put the msvcp100.dll and msvcr100.dll files near your executable file.
As for Qt, the easiest way for windows deployment is to use the windeployqt command prompt util.
Update. How is this usually solved in real applications?
There is no fully automatic tools, which could determine all the dependencies, because the deployment of applications is a complex task. For example, you application can depend on many things such as libraries dlls, compiler's dlls, registry keys, drivers, environment variables, computer reboot requirement, ActiveX/COM components, other installed applications, etc...
But there are tools that can help you in this matter. They can be configured once for target project and then work all the time. This is called Build Automation, another similar concept is a Continuous Integration. As for the creation installation packages for end users, there is a lot of tools such as Nullsoft Scriptable Install System, Inno Setup, Qt Installer Framework, WiX, etc...List of installation software.
the installer script, put a command to download the dll that the application needs to run, and in the application source code, put it to use the dll's ONLY in the folder where it is running
If you are using the NSI installer, use this example
If I write an application using MFC libraries in C++, in deployment stage do I require to install some sort of frameworks or stuff like that?
My intent is to have a standalone exe without complicated installation scripts.
If you're developping a local application for your own organisation, you could go for static linking, as suggested by Danny.
But static linking is not the method recommended by Microsoft: every time there's an MFC related patch (example here) or z patch for another library, you'll have to recompile your code and redistribute or reinstall it in order to avoid PC's being exposed to security vulnerabilities.
This is why Microsoft recommends to use dynamic libraries: these are easier to update/replace (eventually latest versions are already installed; or automatic windows update; or if necessary manual download of the latest version).
If you go for dynamic approach:
there are a couple of mfc*.dll to distribute with your application, together with other standard libraries, such as Msvcr100.dll. It's all explained in the article. Installing such files in your app's directory has the advantage of a leaner installation process. But you have to take responsibility for their update in case of necessity.
or you choose to use Microsoft's redistribuable packages. These can be downloded directly from Microsoft's and are contained in a selff-installable file: vc_redist*.exe. Here some explanations on how to use them in installation process. It might install more dlls than required, but vc_redist is an installed Microsoft product that is kept up-to-date with Windows Update.
If you link MFC statically, there is no need for external files.
Project Settings / General:
Use of MFC: Use MFC in a Static Library
But, as Christophe mentions, it is not recommended by Microsoft.
I have written a portable C++ application using Qt libraries. This means that I cannot use the MT flag for compiling without risking memory issues.
This leaves me with two options:
1) Deploy the portable application with an installer.
2) Package the C++ dependencies within the same folder or use private assemblies.
Both 1 and 2 defeat the idea of portable software, so I was thinking of a third option:
3) Use IExpress to drop the C++ dependencies before launching the application. On exit, delete the C++ dependencies.
Unfortunately, option 3 has received some flak from some stackoverflow members. They even dislike option 2 which leaves me with only option 1. I can see option 1 as doable if I use a portable installer.
Is there such thing as a portable installer? Essentially, I want the installer to check to see if the needed dependencies are installed before running my application (just like a regular installer would) and if they are, then just continue running my application. Otherwise, give a message box to the user that they could download it providing a link to the URL. I am aware I can write my own installer that can do this in C++ but I was wondering if there are any installers that already offer this specific functionality.
http://qt-project.org/doc/qt-4.8/deployment.html
The dlls for Qt in windows are so small, that deploying them with the application isn't an issue in my opinion.
There aren't any programs out there that I know of that place the Qt dlls on windows in some place that another program later would find (like c:/Windows/system32).
I think the only place where you could expect reuse of the libraries is in Linux or a mobile device that has a lot of Qt apps. But even then you have make sure that the versions of the libraries are high enough to support all the functionality that you are using.
Hope that helps.
I want to call a Subversion API from a Visual Studio 2003 C++ project.
I know there are threads here, here, here, and here that tell how to get started with C#.NET on Windows (the consensus seems to be SharpSvn, which I've used easily and successfully on another project) but that's not what I want.
I've read the chapter on using APIs in the red-bean book which says:
Subversion is primarily a set of C libraries, with header (.h) files that live in the subversion/include directory of the source tree. These headers are copied into your system locations (e.g., /usr/local/include) when you build and install Subversion itself from source. These headers represent the entirety of the functions and types meant to be accessible by users of the Subversion libraries.
I'd like to use CollabNet Subversion but there doesn't seem to be API binary downloads, and I'd just as soon not build the whole thing if I can avoid it.
Considering another approach, I found RapidSVN's C++ API, but it doesn't appear to offer Windows API binaries either and seems to require building SVN (which I would be willing to do as a last choice if RapidSVN's API is higher-level than the stock SVN offering.)
Does calling the API from C++ in Windows have to be this much more work compared to using SharpSvn under .NET, or is there something I haven't found that would help me achieve my goal?
You need the dev (e.g. svn-win32-1.6.16_dev.zip) package from here. Probably download also the binaries (e.g. svn-win32-1.6.16.zip) of the tools (DLLs are there).