I created a program using Visual Studio 2010 and it runs fine on my computer, but on another machine it gives this error:
Now, I've done my research and I came up with at least 20 identical answers that all say the same thing: Configure your Runtime Library to /MT (or /MTd for debug) and rebuild. Great, only problem is that I already did just that and it still doesn't work...
Now, the alternative would be to force the users to install the Microsoft VS 2010 C++ Redistributable Package, but I'd very much like to avoid that. So any explanation as to why my solution is not working? Something weird worth mentioning is that my executable size doesn't seem to change even when I rebuild it with /MT, which makes no sense. Also, I'm not using any CLR support.
Thanks for your help.
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 cooperate on a game project in cocos2dx. I do not code, rather work on scenes in Cocos Studio. When I've tried to run .exe build in proj.win32/Debug.win32 it started to throw errors about missing .dll. I've downloaded them as it was requesting them (msvcp140d.dll, vcruntime140d.dll), but I cannot find appcrt140d.dll anywhere.
What would you recommend me to do?
I've tried to install C++ Redistributables without any effect.
The d suffix there means that this is a debug version of the DLL. Which makes sense—like you said, it was compiled as a "Debug" build, which is going to use a special debugging version of the C runtime library designed to help you catch errors.
You aren't supposed to release debugging versions of your applications for general use. In fact, Microsoft doesn't even make the debug versions of its runtime DLLs available. They are considered "non-redistributable." That's why you aren't getting them when you download and install the C++ Redistributables. All you get are the release versions of the DLLs.
If you are not a programmer, you will probably not find a debugging build particularly helpful. The error messages won't mean anything to you, and the extra error-checking code will just slow things down. Unless your friend the programmer has specifically asked you to help him debug his program, then you should ask him for a release build. That way, all you'll need to install is the appropriate version of the C++ Redistributable (version 14 → VS 2015).
If you want to run the debugging build, you'll need to obtain the non-redistributable debug-only versions of the runtime DLLs from your friend. They are installed with Visual Studio. He should know where to find them. If not, tell him to look in his Visual Studio directory (under the Program Files directory), in \VC\redist\Debug_NonRedist\. Copy the required DLLs to the same directory as the EXE and you'll be in business.
Those are debug versions of the runtime environment. They are normally installed when you install Visual Studio 2015. If you do not want to do that, you can find more instructions on how to proceed here: https://msdn.microsoft.com/en-us/library/aa985618.aspx
I'm building a pure Win32 program (no clr or any assembly) by VC 2012 (VC 2012 (VC11) as my compiler). It uses boost 1.58, wxWidget 3.0.2 series,gsl 1.8, jsoncpp, Open CV 2.4.10, etc... The development box is running Win7 64bits. I would like it to be a single executable and is able to run on both Win 7 32/64 so I built all of the above packages as libs myself by the same VC 2012. (thanks for cmake)...
It works fine on development box but not on a clean one that only installed VC redistribution packages. I got the error message box ask me to use the sxstrace and the message in event log has side-by-side error like below and I also tried the sxstrace and got similar error.
"D:\Release\xxxx.exe" 的啟用內容產生失敗。 找不到依存組合 Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"。 請使用 sxstrace.exe 進行詳細的診斷。
I've been searching around. All and answers simply says I should use all release build for all libs. Yes, it's true if I didn't I couldn't have the single executable at first place. It won't be able to link. (I learned it by made lots of mistakes) I've tried both MD or MT build for my program (not mix them together. They are separated test.). Either of the mode works. The same error remains. I've also installed over lots of VC2008 9.0.21022, -.30729.17, -30729.4148, -30729.6161, VC 2010 10.0.40219, VC 2012 11.0.61030 (x86/x64)
I really don't understand. It's pure win32 release build made by VC 2012. How come it requires VC90 debug dll?
I'll really appreciated if someone can give me more precise advice about how to resolve or even determine where and what goes wrong with the code or the lib I build.
I will suggest that you use the following tool: Dependency walker.
By loading your executable on your PC (where it works) you should find out all the DLLs it uses and so discover any hidden dependencies in the (medium sized) library list on which your project depends (and in turn their dependencies).
This should help you point out DLLs that you have on your PC but not on freshly installed machines.
A pure Win32 release build should not depend on DEBUG CRT dlls, that's for sure. The only project setting to control that is basically that MT/MD ("Runtime Library") setting. You want MT.
I would guess that you have the Debug CRT dll referenced somewhere in the source code (e.g. one of the libraries requires it to be linked in for whatever reason, maybe because there is #define DEBUG or something, thus overriding project settings.
You could try searching #pragma comment(lib, ...bla-bla-bla...) in the source code.
It's resolved by myself. The project is about migrating a big legacy project. So there's a very small lib built by VC90 without source code. So be a detail person is the key to do this kind of job.
I have a Visual Studio 2008 (SP1) program, debug build, 32bit, that can't seem to find the debug runtime DLLs (multithreaded debug DLLs).
But the crazy thing is, depends.exe shows the requisite DLLs as being present (and also missing). It actually looks like it's trying to load those DLLs twice.
Below is a link to a screenshot from depends.exe showing what I'm talking about - analysing a library that is part of the solution.
When I launch the program, I get "The program can't start because MSVCP90D.dll is missing from your computer. Try reinstalling the program to fix this problem."
If I go into the sxs directory and copy the "missing" DLLs into the same directory as the binary, the program runs.
The application manifest specifies the correct DLL versions (as evidenced by them being found by depends.exe). I've checked the manifests of that version of the runtime, and to my untrained eye it looks legit.
The binary itself shows the same problem as the DLL examined in the linked image, but also with MSVCP90D.DLL missing (and yet present).
I've tried building with internal/external manifests, turning incremental linking off and on, as suggested elsewhere, all to no avail. I would try linking a non-DLL runtime, however the libraries I am using are shared across many tens of solutions, so changing the way they are built isn't really an option (unless of course that turns out to be the only solution due to a known issue that my googling didn't turn up).
I've tried running sxstrace, but most of the time the output is empty (!), when it isn't empty it shows no errors.
I tried using windbg, but got nowhere as I'm not particularly experienced with the tool and wasn't sure what I was looking for.
I'm running on 64bit windows 7. One of my early thoughts was that having VS2005, 2008 and 2010 all installed on my box was causing some weird issues, but I've found no evidence to support that supposition.
(PS. Looks like similar issue as msvcp90d.dll is missing msvcr90d.dll which as far as I can see didn't actually get solved, and also mentions C# - my project is pure C++).
PPS. Looks like similar issue as "application configuration is incorrect" and "side-by-side configuration is incorrect" running VS2008 64-bit debug build
However that problem was related to 3rd party libraries and 64 bit builds.
In addition the "solution" to copy the "missing" DLLs manually from SxS to the bin directory (which as is mentioned above does the trick) is not a solution at all - at best it's a work-around.
The redisributable does not include the debug DLL files. You need to install Visual Studio to get them.
"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. Debug versions of an application and Visual C++ libraries can only be deployed to another computer internal to your development site for the sole purpose of debugging and testing your application on a computer that does not have Visual C++ 2005 installed."
Here is the topic on msdn about runing debug builds "Preparing a Test Machine To Run a Debug Executable" (solutions and examples are provided):
http://msdn.microsoft.com/en-us/library/aa985618(v=vs.90).aspx
You can choose your version of visual studio (from 2005 up to 2013).
I am using Intel TBB C++ for multithreading an application on visual studio 2008. When I run the executable I get a dialog saying "MSVCP80D.dll" was not found. There is so much on the net about this that it confuses me.
Please help.
EDIT: Based on answers, finally I was able to fix the "dll missing" problem. I had given a path to TBB lib of vc8 leading to dependency on vc8 dlls, which are used with visual studio 2005, not with 2008. (Using depends (http://www.dependencywalker.com/ ) it is easy to determine the run-time dependencies of an executable.) I changed by project to depend on vc9 dlls, not vc8 and then it worked fine.
Another thing to note is use of manifest files on windows. Manifest files describe dependencies. The manifest files must be generated while writing an application as it is necessary.
You can find them online at various places. Just scan it for a virus and put it in your program's path and everything should work fine. You may need more than one of the debug dlls, you can use depends32.exe to see what you are missing.
MSVC80D is VS 2005. As part of VS2008 you would have MSVC90D instead.
Your app is compiled with debug version. Debug version of VC runtime is not in path.
Try to generate release version.
Are you running the program on your development machine? If you are not, you might get this error. The "D" at the end of the filename means that the DLL is a debug DLL, and often not on computers without Visual Studio installed. You're not supposed to redistribute it (copy it around), either. You should compile a "release" version of your application and run that. If you really can't do that for some reason, and it's only one or two computers, then try installing the express version of visual studio on that computer.
If you are having this problem on your development machine, it can apparently be caused by a compiler/linker problem. Try doing a clean build ("clean", then "build" in Visual Studio).
Ok, after a lot of search, and by chance, I landed on this forum http://www.codeguru.com/forum/showthread.php?t=446789 which says something I interpret as "the version of TBB I am using does not support VS 2008".
But this still uncertain.