in the process of creating a plugin that I’m planing to publish as open source in the next weeks, I’m currently facing problems with creating my very first Windows installer. Being a Mac guy for years, I’m generally not extremely familiar with all Windows related stuff and on the other hand, building installers always was some prepared step hidden somewhere in a CI pipeline that was out of my daily job. This is why I tried to stick to the JUCE packaging tutorial as close as possible. Just downloaded the latest version of Inno Setup as recommended there, copy & pasted the tutorial script and customized it to my needs.
As all my steps are based on the official tutorial I wanted to ask here first…
When starting first with the tutorial script, inno setup told me I should replace the deprecated {cf} macro with {commoncf}. I did that, however this lead to an install to C:\Program Files (x86)\Common Files\ in the first try. As I’m building a 64Bit VST3, I want it to be installed to the non-x86 Common Files destination. This is why I changed the macro to {commoncf64}. However, the behaviour is still the same, the plugin gets installed to the x86 location when testing the installer on my machine. What’s also strange is that the setup process doesn’t ask me for the location I want to install the plugin to like it can be seen in the tutorial screenshot.
But it becomes even weirder: I sent the installer to a friend with a Windows machine, where it got installed to C:\Program Files\Common Files\Common Files\VST3 --> an inner nested common files folder gets created here - however, this time in the correct Program Files location
I’m feel slightly confused. Any Inno Setup knowledge round here on the forum?
I don’t see an obvious problem with your script, but one difference is that you are using the {app} constant, which is a directory the user chooses during the install wizard. That’s required for VST2, since there is no standard VST2 location on Windows. But VST3 always goes in Common Files\VST3, so you don’t want the user choosing the directory.
Oh! I just remembered something. Windows installers remember the {app} location you chose last time you ran the installer. That is likely why your plugin was installed to the (x86) directory even after you changed it. Under [Setup] section add:
Thank you for your reply. Tried the changes you suggested (especially UsePreviousAppDir=no was a great hint), however this now leads to an installer not installing anything but some auto generated uninstaller in the target directory. The installer also tells me that I need at least 2,5MB of free space, what is somewhat wrong as my plugin is approx. 7MB large.
So is there any other thing you do in the setup section that differs from the tutorial?
Sounds like it’s installing to the correct directory, so that’s progress! I may have confused things by showing my [Components] section. I would ignore that, and have your Source directive exactly as it was, but with {commoncf64} instead of {app}.
Thanks again! After letting the installer run inside the Inno Setup application & looking at the console output there, I found out that it said it was not in 64Bit install mode. Afer removing Check: Is64BitInstallMode; from the [Files] section, it finally started to work correctly. Still not sure why it sees itself in a non-64 bit install mode when launching the setup on a fresh 64 Bit Win 10 machine, but I’ll just wait what my Windows friends out there in the field experience with this version of the installer
Again I probably confused things by copy pasting stuff from my script without full context. It seems that Inno Setup installs in 32bit mode by default, so the Is64BitInstallMode check would have made it skip the file. Unless you offer both 32 and 64bit versions of your plugin then there’s no need to do the check.
That script is configured to install both 32bit and 64bit versions of a plugin, which is why the check exists. It includes ArchitecturesInstallIn64BitMode=x64 in its [Setup] section, which tells Inno Setup to run in 64bit mode on x64 systems.
Unless you offer both 32 and 64bit versions of your plugin then there’s no need to do the check.