Windows Installer and Runtime files

Today I did a lot of trials with getting a Xojo compiled .exe to run on several Windows systems.
I learned that the Runtime installer - vc_redist.x86.exe- isn’t reliable in any means. Sometimes it works (installs) without issues, sometimes with errors and the Xojo compiled .exe does not run in that case.
So the only reliable way is to install the Runtime files in the same directory as the .exe

What I need is an Inno installer script that:

  • First checks if the needed runtime is already installed
  • If not, it installs all the runtime files in the same dir as the .exe

To be honest, I have zero experience with the Info scripting languages and to learn it for just making one script is not very productive. :slight_smile:
Does any have some pointers or even a script that does this?


If you install the runtime files in the same dir as the .exe, then it doesn’t matter whether the runtime was already installed in the system. The already installed runtime become irrelevant to your .exe because your .exe will look for the dependencies in the same dir first. If it cannot find then and only then it try to look for them in the system dir (SysWOW64 for 32 bit app or system32 for 64 bit app).

So there is no need to check. Just go ahead and copy them into the .exe folder.

If one day, for whatever reason, the user happen to uninstall the already intalled runtime, it will not affect your app.

Here is the InnoSetup script I use, where AppName is the name of the app.
After compiling the script, you will find “AppName214Setup” (see below: OutputBaseFilename) in the OUT folder created (I think) by Innosetup itself.

AppVerName=AppName 2.1.4
DefaultDirName={pf}\AppName 2.1.4
DefaultGroupName=AppName 2.1.4

Name: “desktopicon”; Description: “{cm:CreateDesktopIcon}”; GroupDescription: “{cm:AdditionalIcons}”; Flags: unchecked
Name: “quicklaunchicon”; Description: “{cm:CreateQuickLaunchIcon}”; GroupDescription: “{cm:AdditionalIcons}”; Flags: unchecked

Source: “FolderContainingEXEetc\AppName.exe”; DestDir: “{app}”; Flags: ignoreversion
Source: “FolderContainingEXEetc\AppName Libs\"; DestDir: “{app}\AppName Libs”; Flags: ignoreversion recursesubdirs createallsubdirs
Source: "FolderContainingEXEetc\Resources\
”; DestDir: “{app}\Resources”; Flags: ignoreversion recursesubdirs createallsubdirs

Name: “{group}\AppName”; Filename: “{app}\AppName.exe”
Name: “{group}\{cm:UninstallProgram,AppName}”; Filename: “{uninstallexe}”
Name: “{userdesktop}\AppName”; Filename: “{app}\AppName.exe”; Tasks: desktopicon

Filename: “{app}\AppName.exe”; Description: “{cm:LaunchProgram,AppName}”; Flags: nowait postinstall skipifsilent

I would rather to check it anyways. Personally I don’t like if installer install too much or unnecessary files on my system. It goes without saying I wouldn’t want it to happen with my own apps installer. :slight_smile:

@ Carlo Rubini
Not sure if this script does copy the Runtime files. Or does it?

Sorry. You are right.
In the [Files] section, add:

Source: “FolderContainingEXEetc\x86\*”; DestDir: “{app}”; Flags: ignoreversion recursesubdirs createallsubdirs

where “FolderContainingEXEetc” is actually the name of the parent folder of all your stuff.

Thanks for the help.

I now only need a way to make the script doing a check if it is needed to install the Runtime files or not.

Disadvantage is that you do not profit updates from MS and you can end up having same files, different versions, redundant on may places. I prefer having the Windows OS up to date by install in the system folder when not exist yet.

True, but the problem is that updating isn’t working reliably. On some systems the update is without issues, other is very (VERY) troublesome.
I do not want my customers complain the app isn’t working because the runtime is giving issues.

I’m just curious about this because I haven’t used the installer yet. But using this approach would it not be possible to have a window’s update brake your app as well? I guess this is just the risk/reward decision regarding the two approaches.

I agree on both but still prefer having …Win/System up to date.

Your app are built with the exact runtime version in the exe folder, therefore your app will always work. Any MS runtime update will not affect the runtime in the exe folder and therefore will not affect your app. So there is never any risk. On the contrary, it is well known that MS has screwed up their updates before and cause incompatibility DLL hell issues. Should this happen in the future, you app will never be affected. Your app will always work.

Remember, just a couple of years ago, RB had a single exe distribution. ?