CODEWITHSUNDEEP
c++visual-studioqtvisual-c++visual-studio-2015
Vivian Lobo
Vivian Lobo

Reputation: 623

VC++ Redistributable 2012 or 2013 or 2015?

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).

  1. Why do I need VC++ 2012 and 2013 when I now use only Visual Studio 2015?
  2. 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?
  3. Why do I need to provide both the 32 and 64 bit versions when I compile strictly in the 64 bit compiler?
  4. 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.

Upvotes: 0

Views: 785

Answers (1)

Ben Voigt
Ben Voigt

Reputation: 283634

  1. 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.

  2. Migrate all the files shipped with your application to a version built against VC++ 2015.

  3. You didn't provide any details that could reveal the reason.

  4. 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.

Upvotes: 2

Related Questions