Can't use 32-bit VC++ 2015 on Windows 7 unpatched

Question

I have spent an incredible amount of time getting our product to run properly on customers' machines after we moved to Visual Studio 2015, and I still have one problem left to solve. The problem is that I can't get any of the C++ 2015 redistributables installers to work on 32-bit Windows 7 when it hasn't been patched (Windows Update).

The full story:

We upgraded all projects in the solution from VS 2013 to VS2015 and .NET 4.5.2, which also forced us to upgrade to "Microsoft Visual C++ 2015 Redistributable (x86/64) - 14.0.23506/23026)". We've done this kind of upgrade many times before, from VS2010 and up, and it never failed before.

23506 (for short) are the DLLs that accompany VS2015. We always found it easier to just XCOPY the DLLs into our installation folder. For some reason that doesn't work with the DLLs from VS2015 (23506). The program can't find them even when placed in the same folder as the executables. Why not?

Then I ran vcredist_xXX.exe that accompany VS2015, and the program runs fine.

But I want to XCOPY, so I discovered the download of 23026 from Microsoft, but there are no DLLs in there - only vc_redist.xXX.exe. Still, I copied the DLLs from somewhere in Windows - the paths to each DLL is listed in the registry. By the way, there are two extra DLLs installed that are not present in the folders in VS2015. "mfc140.dll" and "mfcm140.dll". Why?

But XCOPYing 23026 didn't work either, not even with the two extra DLLs. Running vc_redist.xXX.exe from 23026 worked fine.

Ok, problem solved, I thought. Using vc_redist.xXX.exe instead of XCOPYing. But no.

The final problem is that vc_redist.x86.exe (from 23026) and vcredist_x86.exe (from 23506) both fail when run on a 32-bit Windows 7 machine that hasn't been patched (Windows Update) at all after installation. For reasons I won't go into, that's the kind of machines we have to install our product on - unpatched 32-bit Windows 7 - no way around it. (The problem maybe exists on 64-bit unpatched Windows also, but I haven't got the time to find out.)

How do I get around this?

I am trying to link the C++ runtime statically and drop the DLLs alltogether, but it seems impossible when you have native C++ with C++ wrappers in a .NET project. This issue has already been reported by others, so no need to go into it here.

I have tried searching for DLLs to download, or a way to extract DLLs from the installer. Anyway, as mentioned above, I already tried just copying them from somewhere below C:\Windows. Doesn't work, so I doubt I can get some DLLs that will work. But again, why? If somebody can help me figure out this, it could be the perfect solution for our problem.

I have been thinking about finding the exact Windows patch(es) needed to get that installer - vc_redist.x86.exe - to work on those crappy machines. If it's just one or a handful of KBs that doesn't destabilize these machines, that would perhaps be acceptable.

A possibility that definitely should work is to downgrade the C++ projects to VS2013, which doesn't have this problem. I am really fed up of us always having to keep two versions of Visual Studio on our developer machines as a workaround for some silly problem, but if there's no other way, then so be it, even in 2016.

Answer 1

I was able to get this resolved on my local PC by following the updated step 6 on that article: https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/

Once you copy the 20 or so DLLS folder it still didn't work for me, I had to grab the ucrtbase.dll and ucrtbased.dll along with all the usual 140 (mfc, mfcm,vcruntime, msvcp) from my SysWOW64 folder and finally i'm able to launch this on a windows 7 pc without requiring to install any patches!

Answer 2

Found a quick and simple workaround. Turns out we only need to change the setting "Platform Toolset" to "Visual Studio 2013 (v120)" in all the C++ projects, in order to build with the good old DLLs that still work with XCOPY deployment. I was under the impression this setting would not go together with .NET 4.5.2, which we need, but it does. VS2013 will have to be installed along with VS2015, but we can live with that.

As stated, this is a workaround. It doesn't solve the actual problem stated in the title. But since I actually asked for a way around the problem, I'll close the issue with this answer.

As for the actual problem, if anyone is interested: I found some blog entries on the Visual C++ Team Blog - "Introducing the Universal CRT" and "The Great C Runtime (CRT) Refactoring". Where that leads, I'm not sure.