VcRedist | Lifecycle management for the Microsoft Visual C | Azure library

In my C# WPF application I want to install an other program. The other program consists of a setup.exe, multiple msi files and a vcredist.exe. I need to start the setup.exe because it hands over some parameters and information to the msi files and uses an update functionality for the existing version of the program. So I can't start the msi files directly.

I am trying to install VC_redist.x64_v14.27.29016.0.exe using NSIS installer in silent mode with no interaction. This is the code:

I have a Windows x86 32 bit desktop application built using Visual Studio 2015 written in C and C++ using the MFC framework for the User Interface. For the installer I am using NSIS compiler with an NSIS script to generate the installation .exe used to install the application which is composed of some 10 different components, .exes and .dlls that are created by the build.

My desktop application is a point of sale application that runs under 32 bit or 64 bit versions of POSReady 7 (Windows 7) as well as Windows 10 and Windows 10 IoT Enterprise (not Windows IoT Core) on Intel x86/x64 compatible CPUs.

When I changed from Visual Studio 2005 to Visual Studio 2015, I was struck by the larger size of the installation executable, from a size of roughly 8 MB to a size of 16 MB. The size difference seems to be due to the Visual Studio 2015 C++ Redistributable that I am including in the desktop application installer.

The NSIS script has the following lines:

I am having issues trying to install numpy for pypy3 on my Windows 10 machine.

As I am unable to tell if this problem stems from my pypy3 installation or from something else I am describing here all the steps that I have followed so far:

As indicated on the official download page I have:

• downloaded and installed the "Visual C++ Redistributable Package" vcredist.x86.exe
• downloaded and installed the Pypy3 "Windows binary (32 bits)" file pypy3.6-v7.3.1-win32.zip

Then after having manually added pypy3 to the PATH of my machine, I have:

• installed the pip package from the shell with the command pypy3 -m ensurepip

The problem arises when trying to install numpy. The official documentation says that one can install it by doing pypy -m pip install numpy (pypy3 in my case) but doing so throws the following error:

With this code: Install DirectX & VCRedist in freearc default script when progress bar is full & paused after main file extraction I can install DirectX and VCRedist with Inno Setup. But, is it possible to force the installation window of these programs to a certain place on the screen? For example:

I'm trying to run a certain program (PCXS2), but after looking at the .exe with Dependency Walker, i figured out i needed 2 certain .dll files (ext-ms-win-ntuser-uicontext-ext-l1-1-0.dll, and api-ms-win-core-shutdown-l1-1-1.dll), but the program only takes x86 dll files and the only available versions are x64 files. How can I convert the dll files to x86?

I'm on a 64 bit computer running Windows 8.1, and have most of the vcredist patches for my OS. I have tried putting the files in System32 and running the dll register code in cmd, but to no avail.

The text I get when running Dependency Walker:

Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.

Error: Modules with different CPU types were found.

Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

(For context the CPU value is highlighted red.)

TL;DR - The MS docs state that binary compatibility between VS2015 and VS2017 libs is one-way, while I'd assumed it is necessarily two-way. Where's the catch?

First, for background:

• Any MSVC++ built libraries are officially binary compatible between VS2015 and VS2017.
• Specifically, you can use your VS2015 C++ app with the MSVCRT140 version from 2017. (VCRedist backwards compat)
• The official documentation site states a confusing restriction.

Background / related Questions:

• Is Visual-C++-2017 binary compatible with VC++-2015?
• Questions about "Binary Compatibility between Visual Studio 2015 and Visual Studio 2017"
• Binary compatibility between VS2017 and VS2015

The confusing restriction I find is:

There are two exceptions to this rule. Binary compatibility is not guaranteed in these cases:

...

When consuming libraries built with a toolset whose version is greater than the toolset used to compile and link the application. For example, a program that is compiled and linked with compiler version 19.12 can consume libraries that are compiled with 19.0 up through 19.12.

This caveat is, IMHO, both technically sloppy and confusing. What would the technical reason be for that?

I say it's sloppy because it is incomplete, because the interface between an executable and a DLL is pretty syymetric, but this bullet only covers "the application".

Specifially, and assuming all modules are built against the dynamic CRT version and this dynamic CRT version is the newest version available, I see the following combinations where binary compat is an issue:

• my_2017.exe <-> my_2015.dll -- seemingly supported
• my_2015.exe <-> my_2017.dll-- seemingly unsupported
• my_2017.exe <-> my_2015.dll <-> my_2017_x.dll -- what now, in which "direction" is this supported btw DLLs?

Since binary compat - purely from the binary/interface perspective - must run both ways, I don't quite see where we suddenly could get an incompatibility here: API calls can go both ways (callbacks etc.), objects "move" both ways, even the order of DLL loading can be mixed.

This is an important point IMHO, as it means the binary compatibility as stated is severly limited:

• If my application want's to consume any VC14* compiled library, I "officially" still must make sure that my application is built with the "newest version".
• On the other hand, if don't build an "application", but have a DLL, I can seemingly consume any other VC14* DLL and be compatible?
• With the VCRedist, we have exactly the case that is seemingly unsupported, namely we are allowed to consume a VC2017 library (CRT in this case) from a 2015 app!

So, why(!) is this limited in the way it is, and how does it relate to inter-dll dependencies and also the inverted(!) CRT-dll version requirement.

Good day! I use Wix v3.11 to create MSI, and my project uses merge module for VCRedist. After getting the warning that I should "set the Package/@InstallerVersion attribute to 301 or greater to merge this merge module" I noticed that by default WiX sets Package/@InstallerVersion to 200. Why? Modern versions of Windows come with Windows Installer 4.5 and greater (here is the table from MS).

I have a ASP.NET 3.5 application that includes a 32-bit DLL. It works fine (and has for years) on Windows XP, 7 and 10. I am adding support for Windows 2012, 2012 R2 and 2016. It works on 2016, but does not work on 2012 R2.

At the first call to the DLL, the following error occurs:

BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

The same build and install script is used for all OS's tested. Each OS is on a VM on the same machine, so the hardware for all OS's is identical. For each OS:

• OS is fully updated.
• vcredist 9.0 (x86) is installed as part of the installation.
• IIS DefaulatAppPool has 32-bit applications enabled.

I've tried all the suggestions in the posts I've found on this problem, but nothing works. Any ideas?