I have an application written in QT. Previously I was using Visual Studio 2012 and Qt 5.3.1 after which I recently upgraded to Visual Studio 2015 and QT 5.6. I would previously provide msvcp110 and msvcr110 as part of the installation (I know that wasn't the best practice but I got away with it).
After upgrading I had to now install VC++ 2015 because of the changes with VS 2015. I don't mind the changes and currently providing redist packages to be installed.
The problem I am facing is that, I do have to provide VC++ 2012 as well and recently running the software in Windows 8.1 Pro, I was asked to provide VC++ 2013 as well (never used VS2013 for compiling). The diagnosis was from dependency walker and google. Not only that, I had to install x86 and x64 of all the 3 versions of VC++ for the software to start (wouldn't even start to be honest).
Why do I need VC++ 2012 and 2013 when I now use only Visual Studio 2015?
How do I get rid of the other redist packages? Is it some code I have written which is dependent? If yes any chance I can find out?
Why do I need to provide both the 32 and 64 bit versions when I compile strictly in the 64 bit compiler?
Any way to diagnose without dependency walker? Can there be some logging when the application refuses to start at all?
Apologies for the long post, but any light here can restore my sanity.
Thanks in advance.
You are using DLLs linked to the older runtime. You can use Dependency Walker on your development machine to track this down, shouldn't need to install any tools on a customer machine for that.
Migrate all the files shipped with your application to a version built against VC++ 2015.
You didn't provide any details that could reveal the reason.
For DLLs other than the language runtime library, you can use delay-loading and then be able to trap failure to load the library. You can't effectively delay-load msvcr*.dll though. One option would be to create a very thin EXE that uses no support DLL at all (either use pure Win32 API, or statically link the runtime) which does nothing except install an error handler and then load your main program which is now in the form of a DLL. Loading your main program DLL should be done either using delay-load linking or LoadLibrary()+GetProcAddress() -- either one will allow catching errors. This main program DLL would be free to import the runtime DLLs as usual.
Related
I'm very new to GUI programming in c++, thus I don't have that much experience.
I created myself a GUI for my programm using the Visual Studio 2017 CRL package and now I'm trying to make this exe available for everyone.
The application works fine for those who have Visual Studio or VC Runtime installed but for those who don't the programm throws something like: "vcruntime140.dll is missing on your computer to run this app".
I am not sure how to link these dll's in my programm so that EVERYONE is able to use it.
I'm also not quit sure how I would link dll's.
There's basically two options.
The Standard in the industry is to ship the Visual Studio 20xx Runtime Redistributable Installer alongside your program, and have it run before anyone tries to run your program themselves, to make sure that the .dll files are installed onto the target computer.
The other option is to change the way that the libraries are linked to the executable at compile-time. This is done with a flag in Visual Studio:
Basically, you want to change the Runtime Library field to either say Multi-Threaded or Multi-Threaded Debug depending on whether you're in Release or Debug mode, as opposed to "Multi-Threaded DLL", which is the default.
Note, however, that you need to make sure that every single library you're using was compiled the same way: if any of them were compiled using the DLL version of the Runtime Library, they'll interoperate with your code in funny ways, and the least of your problems will be that they'll need the DLLs installed anyways, defeating your effort.
Naturally, that's not an issue if all your libraries are Header-Only, but if any of them have been compiled, then you'll need to recompile them using the correct settings.
You need to install Visual Studio 2017 redistribuables on the machine (that's how it works for every version of Visual Studio).
However, I could not find any official link on Microsoft website (probably because this is not officially released yet)....
You probably need to use 2015 version (for which redistribuables are available here) and wait for 2017 to become an official release.
I have a software with a couple of executables, that depends on both VC++ 2012 and VC++ 2010 (msvc110.dll, and msvc100.dll, something like that). I want to ship my application with the 2012 version redistributable, that is 7mb, and avoid using the 2010 redistributable so I reduce the size of the installer.
My question is, is the 2012 version of the redistributable backwards compatible with the 2010 version? Or should I embed both of them in the installer?
Note that the executables are already compiled, and I don't have the source code to compile them using the same version.
Unfortunately if you don't ship the runtime the module was compiled against,if it does not exist on the target system, your app will fail. How it fails depends on how you built your app (e.g. linked lib dll, versus OpenLibrary module).
As for compatibility, our team had similar questions so I wrote experimental test code using VS2005, VS2010 and VS2012 modules where one module would create a std::vector (etc) and pass it to another module for use. It failed badly. Extremely easy to reproduce this experiment.
You will need to ship both.
You have several exe, just ship them all or mark it down as a requirement for your app.
DLLs are not big.
If you can rebuild apps to align them so they use the same crt, that would be better.
How to remove msvc dlls (example: msvcr100.dll) dependency to run qt appliation?
I've developed a qt application which runs just fine in dveloper machine but unable to run on any other machine gives error message "program can't start because MSVCR100.dll is missing from your computer". I can solve this error by copying that file in the application folder but I dont want to copy, instead I want to link statically or some other way to remove that dependency.
Thanks in advance
The issue is that you are probably trying to run an application on a machine which has a different Visual Studio (MSVC) version installed than the version that was used for building your application itself.
Generally, the correct solution is to install the corresponding Visual Studio redistributable package on the target machine. It is not a "workaround" or "hack" because if you wish to use an application built with different runtime libraries, etc, then it is expected. Here you can read a bit more about it:
Redistributing Visual C++ Files
Yes, it is a bit unfortunate, and apparently MS has not managed to make it the most ideal, but after all, it is simple enough to circumvent. Note that the target machine would not only have issues with your application, but in general with any distributed in a similar fashion.
The other way to solve the issue is to build the application with the same environment that is installed on the target machine, but this can easily go haywire if you need to supply the application to several machines with versatile setup. Now, I would say this is the "hackish" approach.
You will need to grab the redistributable for this particular problem from here:
Microsoft Visual C++ 2010 Redistributable Package (x86)
Microsoft Visual C++ 2010 Redistributable Package (x64)
Even if you went down for statically hacking this around somehow, you would need to deal with nasty consequences when using your application with DLLs and static libraries, etc.
As far as I know, you can't link statically to Visual Studio Redistributable. Any application built with Visual Studio Compiler needs the corresponding msvcXXX.dll to run. Installers containing all dll for each specific version of MSVC are available here: http://search.microsoft.com/en-us/DownloadResults.aspx?q=redistributable
If you want avoid errors for your users when you distribute your application, you have some solution. A commonly used is to install the right redistributable package before installing your application on the user machine. Often used tools (NSIS, Inno Setup, etc.) have options to run other executable in the process. And each Microsoft redist package can be run silently (without any window display to user).
Note: This problem is absolutely not related to qt. It comes directly from the compiler you choose.
I am running Microsoft Visual Studio Express 2012 for Windows Desktop on a 64 bit machine with windows 8.
I create a completely new Win32 Console Application (in C++) and accept the default options. I then build and run the solution in both debug and release modes and it works all find and dandy. Next I configure the include and library directories for the dynamic SFML library. I link to the debug and release .lib files and put the debug and release .dll files in the proper directories. I then add some simple code which uses the library, build and run the application in debug mode and I get this error: "The program can't start because MSVCR100D.dll is missing from your computer. Try reinstalling the program to fix this problem." If I build and run the application in release mode it works with no errors. (And yes I have the redistributables installed 32 and 64 bit.) Now from what I understand and according to this thread that .dll file is for debugging only and is not included in the redistributable package (which would explain why it doesn't work in debug mode). The answer says that developers have it installed with visual studio by default. This is obviously not the case as evidence from the error and I've reinstalled visual studio and restarted my computer twice now.
In conclusion, how do I simply compile my solution in debug mode without getting this error?
I'm afraid someone will mark this as a duplicate so here we go:
LINK - "...you appear to be linking to the debug version of the runtime, it is not normal to distribute apps linked against the debug version of the runtime."
Doesn't pertain to me because I'm not distributing this app, just trying to run it in debug mode.
LINK - "I compiled my program using Microsoft visual c++ 2010 Express Edition and tried to run it on another machine that did not have the same compiler."
This person get's the error when he runs what hes compiled on a different computer, not when actually compiling the application.
LINK - "If you get this error for your release build..."
I dont.
LINK - "You can compile your project in "Release"..."
My project is not ready to be released therefore I should compile my project in debug mode.
MSVCR100D.dll is the dll for Visual Studio 10, so somewhere something is depending on it (the SFML dlls?). Whatever you compile (in debug mode) with Visual Studio 2012 will require MSVCR110D.dll, which you should have available on your machine as part of the installation.
I suggest you build SFML yourself on your own version of Visual Studio, it's pretty easy. In fact, the binaries available on the site as part of the SFML 2.0 RC are rather old and you'll do yourself a huge favor by building from the latest sources, as a lot of fixes and improvement were applied in the meantime.
(Also, definitely use 2.0 instead of 1.6. The site is rather misleading, but on the SFML forums virtually everyone will recommend you use the last version)
This message generally states that the dll is referred to directly or indirectly in your application and is missing.
The 'D' at the end show us this is the Debug version of the file, this is DLL file is provided with the Visual Studio 2010 installation. So the MSVCR100D.dll would be provided with the installation of Visual Studio 2010.
Of course, you could be missing other versions 2008 (MSVCR90D) 2010 (MSVCR100D) 2012 (MSVCR110D) or the 2013 (MSVCR120D), each dll is provided according to the Visual Studio version.
There are a few ways to solve this:
Check to be sure that you're compiling all the components of your
project in Release mode. If this does not solve the issue continue
to the next steps.
You could solve this locally by installing Visual Studio 2010 on your
machine. This is not what I would recommend, but it would surely
overcome the issue
You could also download the file from this third party website and
copy it to your projects bin:
http://www.dll-files.com/dllindex/dll-files.shtml?msvcr100d
This option is the LEAST recommended option.
Run dependency Walker and see what file depends on the MSVCR100D.dll
and the try and fix that file in order to break your dependency. You can download depends here: http://www.dependencywalker.com/
Check to be sure that you're project is linking the correct version of
the CRT and any other libraries you may be using (e.g., MFC, ATL,
etc.)
Note: Installing the redistributables alone will NOT solve this problem, since the redistributables only contain the release version of the file MSVCR100.dll (notice no 'D')
MSVCR100D is part of the 2010 Visual Studio package - indicating that some components of your system are compiled with the older version of Visual Studio, so you will need to install the Visual Studio 2010 version - you can probably still develop with the 2012 version, just as long as [parts of] the 2010 is on the machine.
Or you need to recompile some components that your application depends on to use the 2012 (msvcr110d) libraries - if you have all the source code, that would be my preferrred method.
I've got a problem with several VC++ DLLs, which I should include into my .NET/C# project. One VC++ DLL is a C++/CLI DLL, which I use as public interface from my .NET project. The other DLLs are written in native C++. I have no access to the source of the VC++ DLLs, I just have to use them.
I've made a .NET test project and referenced the C++/CLI DLL. No problem, compiler is lucky, great. There's just one problem: when I start the EXE of the .NET program, I get errors about the C++ DLLs because of missing VC++ core DLLs.
sxstrace shows the following (shortened):
INFO: Reference: Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195"
INFO: Reference: Microsoft.VC80.OpenMP,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195"
INFO: Resolving reference Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195"
...
ERROR: Cannot resolve reference Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195".
Now I'm no fool and tried several things. I've read much about WinSxS to get a deeper understanding about what's going on.
Now I'm at the point, where it's getting weired for me. The system where I want to execute the program has the VC++ Redistributable package in the current version 8.0.50727.762 (SP1) installed. I know that there's a policy file for Microsoft.VC80.CRT in winsxs that redirects all versions of this assembly to the current version 8.0.50727.762 (that's the solution for the problem at http://blogs.msdn.com/b/nikolad/archive/2007/03/29/a-solution-to-two-references-to-different-versions-of-crt-mfc-atl-in-one-application-manifest-file.aspx).
But as the error above says, this policy file doesn't seem to work or isn't taken into account. The system just wants to find the 8.0.50727.6195 version of the assembly.
Now that's the first question: what's the problem here? After I got this figured out, I could solve the initial problem...
Ok, now it works - thanks for your help.
I figured out two problems that had to be solved:
1) I had to install the "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update", which deploys version 8.0.50727.6195 of the VC++ assemblies. This update was hard to find at the Microsoft servers, so here's the link: http://www.microsoft.com/download/en/details.aspx?id=26347
Normally you only find the 8.0.50727.762 version ("Visual C++ 2005 Service Pack 1 Redistributable Package), which is outdated. Since the C++ DLLs were compiled against 6195, installing the update solved the first problem.
2) While the C++/CLI DLL was compiled in Release mode, the native C++ DLLs below had been delivered in Debug mode. Now the Microsoft license agreement prohibits deploying the VC++ Debug DLLs and the VC++ Redist Packages don't include the VC++ Debug DLLs.
http://msdn.microsoft.com/en-us/library/aa985618.aspx says:
Debug versions of an application are not redistributable and none of the debug versions of the various Visual C++ dynamic-link libraries (DLLs) are redistributable.
Solution: the developers of the native C++ DLLs gave me a release version and everything works fine...