My application when opened in others computer will give an error missing msvcr"something".dll, I found out that to fix this they need to install the following:
http://www.microsoft.com/en-us/download/details.aspx?id=40784
Which is Visual C++ Redistributable Packages for Visual Studio 2013.
I would like to compile the program with the dlls in the executable already, is such thing possible?
If not possible, where can I get all the dlls to put in the compiled project folder?
Try to set /MT for Release and /MTd for Debug in Project Settings->C/C++->Code Generation. This will make your program not dependent on Visual Studio libraries. But beware that all the libraries/ projects you will link with should also have the same option there, otherwise you'll get nasty linker errors.
You may also wish to select v120_xp in General->Platform Toolset for your program to be able to run on Windows XP
Because a lot of Programms use the functionality of these dll's they are dynamically linked.
So your filesize stays small and in case of fixes within the dll you dont have to recompile your program.
If you dont want this behaviour you can set in the projectsettings the dll's to "static linked" (/MT).
That way they will be compiled into your executable
Here is a relevant MSDN-article
Which is Visual C++ Redistributable Packages for Visual Studio 2013.
For Visual Studio 2013, you need:
http://www.microsoft.com/en-us/download/details.aspx?id=40784
If you were building with Visual Studio 2012, then you would need:
http://www.microsoft.com/en-us/download/details.aspx?id=30679
If you were building with Visual Studio 2012, then you would need:
http://www.microsoft.com/en-us/download/details.aspx?id=5555 (x86)
http://www.microsoft.com/en-us/download/details.aspx?id=14632 (x64)
The point is, you are probably going to need a runtime if you are writing portable C/C++ code by using functions like new, malloc, delete, free, etc.
You might be able to avoid the code if you use the Win32 API. For example, HeapAlloc and HeapFree, etc. Installers often use the Win32 API, and that's one of the reasons they usually don't need a runtime installed prior to running them.
I would like to compile the program with the DLLs in the executable already, is such thing possible?
Yes, its possible. Its called Static Linking (as opposed to Dynamic Linking).
But you will probably still need a runtime.
If not possible, where can I get all the DLLs to put in the compiled project folder?
Retired Ninja gave you this answer: Microsoft Visual Studio ~ C/C++ Runtime Library ~ Static/dynamic linking.
My application when opened in others computer will give an error missing msvcr "something".dll" ...
Another possible solution is to build your project with Visual Studio 2005 or Visual Studio 2008. The runtime used by VS2005 and VS2005 are usually available on Windows Vista, Windows 7, and Windows 8. So the computer may already have them.
But usually you just build your installer to carry around what you need. I use Inno Setup because it allows you to include both x86 and x64 components side-by-side. At install time, you just install the right components based on architecture (x86 vs x64), including the correct runtime. (At the time I choose Inno, Wix did not allow mixing architectures and I wanted a unified installer).
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 am dynamically loading (server) jvm.dll into my 64-bit Visual Studio 2013 C++ application using LoadLibrary(), in order to execute native Java code using JNI.
In the VS debugger, I am getting a number of access violations as the dll is being loaded (yet things seem to work if I 'continue' after these); and then a hard crash when some JNI calls are being invoked. I have tried jvm.dll's from Java 1.7 and Java 1.8, with the same issues.
I suspect the issue to be runtime library incompatibility. Dependency walker indicates that even the latest jvm.dll depends on msvcr100.dll (from Visual Studio 2010). I have heard dire warnings of the consequences of using incompatible runtime versions; and have seen the results first hand in other instances.
Has anyone else run into this problem? Is there any version of jvm.dll available that is compiled against Visual Studio 2013?
Thanks,
Dan
Just recently (Feb 2015) I compiled a JNI application which invokes the JVM to run a Java program. I used the most recent JRE version (1.8.0_31) and Visual Studio 2013. I am also loading the jvm.dll at runtime. Take a look at this post if you want to see how I setup my JNI calls.
So it is possible...
Make sure that the JRE containing jvm.dll is built for the same architecture (32bit or 64bit) as your Visual Studio project. If you are using 64bit, you may need to add the x64 as your configuration. To do this go to:
Solution --> Properties --> Configuration Properties
Also make sure your includes/libraries are correct.
For my project, I needed to include the following:
C:\Program Files\Java\jdk1.8.0_31\include
C:\Program Files\Java\jdk1.8.0_25\include\win32
Also, I needed to include jvm.lib which is located at:
C:\Program Files\Java\jdk1.8.0_31\lib
Make sure you also add the jvm.lib to your linker input. Alternatively you can use the preprocessor:
#pragma comment(lib, "jvm.lib")
Hopefully, this should help get your project configured right. If you are still having errors, I would recommend uninstalling Java completely, and re-installing after. Perhaps the same with Visual Studio 2013 as well...
Is it possible to change the restrib file to msvcr100 so other computers can run the program without having problems with the .dll file? If so how do i get that?
I do compile the program and other people can't use it because of the missing msvcr120.dll file. So it would be great if i could change that somehow.
Is it possible to install the Plattformtoolset without a older Visualstudio version?
You have a few choices:
Install VS2010 on the machine, and set the Platform Toolset option to v100.
Install the Windows SDK v7.0A from here, which SHOULD / CAN add a new option to your Platform Toolset menu in VS2013. Getting this to work can be quite fiddly though. (It's rarely worked for me right out of the box). Note if you use MFC in your application, this option isn't any good for you - MFC libraries are not included with this SDK.
Get your users to install the Microsoft VS 2013 C++ Redistributable Package from here, and carry on regardless.
Statically link to the VS2013 runtimes, instead of using dynamic linking to the runtime DLLs. You can set this in the IDE through project settings under C/C++ > Code Generation > RunTime Library > Multi-threaded (/MT) or (/MTd). All the needed code will be compiled into your app, which will make the files bigger, but will avoid the issues you mention.
In Project > Properties > General, there is a setting called Platform toolset. You can use that to change the version of the build toolchain used.
One thing to consider in regards to changing the platform toolset: it changes the compiler, so C++ features newer than Visual Studio 2010 will not compile. It also requires the other version to be installed.
The best way to handle this would be to give them the Visual C++ Redistributable for Visual Studio 2013.
You could either have them do it themselves, or make an installer.
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.
Consider a machine(64bit) is not having visual studio 2008 and redistributable package x64,
1. To run 64bit application(built by visual studio 2008 sp1) on that machine, do we need Redistributable package on that ?
Consider a machine(64bit) is having visual studio 2008 but it is not having redistributable package x64,
2. To run 64bit application(built by visual studio 2008 sp1) on that machine, do we need Redistributable package on that ?
what is the relation between redistibutable package x64 and 64 bit applications ?
First off, this requirement exists for both 32-bit and 64-bit code. You're just a bit more likely to be lucky with 32-bit code and somebody else having it installed before you. As it was on your dev machine by the VS installer.
It is induced by a compiler setting. Project + Properties, C/C++, Code Generation, Runtime Library setting. All the project templates in VS have this setting at /MD. You can change it to /MT and no longer have a dependency on the runtime DLLs, like msvcr90.dll. The runtime library code will be linked into your program instead of relying on the DLLs to be present on the target machine.
You have to be careful however, the /MD setting is the safe setting. It ensures that you won't get into trouble when you create your own DLLs and write code that returns C++ objects (like std::string) or pointers that must be released by the caller. This won't work well if the DLL and the EXE each have their own copy of the CRT linked into them. They will use different heaps, releasing a pointer across heaps cannot work properly. A silent leak on XP, a crash on Vista and up.
The redistributable .exe is actually meant as a downloadable installer that your customer can use when you forget to write an installer for your program. The much better solution is for you to write an installer that gets everything copied and installed properly. It takes less than a minute to make one. Add a Setup and Deployment + Setup project to your solution. Right-click it, Add, Project Output. Project + Properties, Prerequisites and tick the "Visual C++ Runtime Libraries (x64)" checkbox. If you prefer to create your own installer then you can use the merge modules in C:\Program Files (x86)\Common Files\Merge Modules
Oh, and deploy the Release build, not the Debug build. The debug version of the CRT is not distributable.
In many cases, you can link your programm statically against the C runtime library. In this case the redistributable package is not needed because all necessary functions are copied into your application's executable. If you however link against it dynamically, you should deliver the redistributable package with your application. While many other applications do this as well, there is no guarantee that the necessary runtime is available on the target system.
You can change how you link against the runtime in your project's settings dialog under "C/C++ > Code Generation > Runtime Library".
The following MSDN article explains how you redistribute the necessary VC++ files: http://msdn.microsoft.com/en-us/library/ms235299%28v=vs.80%29.aspx