I've generally assumed that each version of Visual Studio was tied to a different version of the C run-time. For example: VS2005 : msvcr80.dll :: VS2008 : msvcr90.dll
One of my co-workers told me that his installer indicated that our VS2013 project had a dependency on msvcr110.dll. We both found this odd, because this is the same dependency used by VS2012.
However, MSDN backs this up:
Visual Studio 2012 C Run-Time Libraries
Visual Studio 2013 C Run-Time Libraries
Does Visual Studio 2013 indeed reuse the run-time from 2012, or am I missing something?
Edit: I forgot to mention in my original question that the Visual Studio 2013 redistributable run-time comes with a file msvcr120.dll. My confusion comes in from the fact that this file exists, yet is neither identified by our installer nor mentioned in the MSDN documentation.
Edit: After talking with my co-worker about how the dependency was being determined, the reason the installer thought our projects had a dependency on msvcr110.dll was because it was looking at an old build.
This just unfortunately coincided with the copy/paste error in the MSDN documentation regarding the versions of the run-time. I'll contact Microsoft to let them know about the documentation error. Thanks again for the help, everyone.
Note: Even if they did use the same run-time, I wouldn't assume such for any future releases. I just found this curious.
By default VS 2013 C and C++ projects will depend on msvcr120.dll (or the debug build equivalent of msvcr120d.dll).
However, it's very easy to change the dependency to msvcr110.dll by changing the 'platform toolset' to "Visual Studio 2012 (v110)" in the project settings if VS1012 is installed on the machine. Older versions of the runtimes going back to VS 2008 (v90) are supported.
I assume that the doc page for the 2013 runtime that you linked to wasn't updated due to a simple oversight.
Related
Is there a reason (I guess yes but I try to discover it) to install 2019 redistributable when deploying a C++ application built with vc142 since applications seems to work perfectly with the previous redistributable package (coming with vc141)? I have in mind that both are binary compatible, but more than that, dumpbin /exports of msvcp140.dll and vcruntime140.dll from 2017 and 2019 redistributable produce the same output; file size are identical too.
Did I miss something?
Apparently there is no gotcha, the libraries are comptible, see : https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2019
The article states: "This reflects the fact that both the runtime libraries and the applications compiled with either version of the compiler are binary compatible."
Maybe there are performance related differences.
As vs 2019 supports later c++ standard than 2017, this leaves one to wonder how this is possible with the old runtime libraries. I guess the differences are all built into the main executable/dll and don't require any changes in the runtime dlls.
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...
I have installed MS VS Express 2013 on my office computer, and compiled a DLL with it. Now when my colleague is trying to use it, she gets an error about a missing MSVCR120.DLL. We have found MSVCR100.DLL on her PC. I know that we can get MSVCR120.DLL from Microsoft. However
it will probably require admin rights, and only I have them in our team. I wonder if I can ask VS 2013 to compile the DLL so that it uses older version of redistributables? Or is installing the previous version of VS the only solution?
I found the solution — here: https://stackoverflow.com/a/1073772/674976. The distributable DLL can be statically linked to my DLL, thus removing the dependence. This is done in VS 2013 in Project Properties (Alt + F7) > Configuration Properties > C/C++ > Code Generation > Runtime Library, which should be set to Multi-threaded (/MT) from the default Multi-threaded DLL (/MD).
However, I wonder if by doing so I am actually still using redistributable DLLs of two versions and thus risk mixing the heaps and potentially causing memory allocation problems.
If someone suggests a better solution or a clear explanation why I should simply use Visual Studio 2010, I'll be happy to accept it is an answer.
Visual Studio 2013 can build Visual Studio 2010 C++ projects. To do this, you need to also have Visual Studio 2010 installed, because VS2013 will actually call the VS2010 C++ compiler.
What I have done to accomplish this is to create the solution and all the projects in Visual Studio 2010 and make sure that they build and run correctly. Then open them in Visual Studio 2013 and make sure to NOT upgrade the projects to VS2013.
Now you can use the latest tool and still build the VS2010 dlls that you need.
I have created an application on Windows XP, Visual Studio 2005, C++.
I want to run the application using its .EXE file on a different computer but it crashes.
I think it maybe related to some .dll missing files.
Am I in the right direction?
If so, how do I know which files are missing?
Is there a build option in the Visual to copy all the requested .dll to a specific place?
Thanks,
Asaf
The most likely answer is that the other computer is missing the Microsoft VC++ redistributable files. You can download the VS2005 (or VS2005 SP1) file from Microsoft. It's name is vcredist_x86.exe (assuming standard x86 build). Just run it on the target PC and then retry your app.
If you assume it is a missing DLL you can also use the Dependency Walker
But I agree to Joel that most probably it will be the redist package that is missing or if you tried to use a debug version you might need the non redist package.
But you don't have to download them. They should be part of your VS installation. Somewhere in the VC/redist folder.
I use dependency walker to watch which dlls are missing for my program.
There's an in depth discussion of the options and steps required to get Visual Studio 2005 C++ Applications to run on machines which don't have Visual Studio installed here.
It includes detailed instruction for Visual C++ Express users too.
I own VS 2008 Pro, and would like to do compatibility testing with VS 2005's runtime MSVCRT80, but I do not want to buy it just for that. Is there a way to link against MSVCRT80 without getting VS 2005?
Thanks
Official support for native multi-targeting didn't appear until Visual Studio 2010, which allows you to select either v100 or v90 as your "Platform Toolset". There is no such feature in Visual Studio 2008.
There is a discussion here on how one can achieve the same effect in Visual Studio 2008, but it appears you need to have VS 2005 installed on your computer as well in order for this to work. It isn't going to work if you just have the runtime libraries installed because you need the proper version of the compiler and linker, which you'll only have if you install VS 2005.
On that note, I'm not really sure what you mean by "compatibility testing". If you compile your app against v90 in VS 2008, it's not going to work with the older versions of the runtime. You have to compile and link against the version you want your app to use.
Finally, consider whether it's really relevant or not. Since you must include MSVCRT with your application anyway, what's the advantage of trying to link against an older version of the runtime? Just include v90 and be done with it.
Links to a still-working (as of 11 Jan 2011) Microsoft download for Visual C++ Express 2005 can be found here:
http://apdubey.blogspot.com/2009/04/microsoft-visual-studio-2005-express.html
This should let you compile against the VS2005 runtime without having to buy anything.
(in case the blogspot article goes away, the link for the .iso is http://go.microsoft.com/fwlink/?linkid=57034).