Inno Setup is Flagged as Trojan?
-
@Christoph-Hart said in Inno Setup is Flagged as Trojan?:
Or don't give in to the code sign mafia and raw dog your installers to your customers like a real man!
:face_with_tears_of_joy: :face_with_tears_of_joy: :face_with_tears_of_joy:
-
Who cares about installers, I'm gonna zip this bad boy up, and let the customers figure out the rest.
-
@ThinkTank said in Inno Setup is Flagged as Trojan?:
Who cares about installers, I'm gonna zip this bad boy up, and let the customers figure out the rest.
Good luck :)
-
@aaronventure said in Inno Setup is Flagged as Trojan?:
I'm looking to see if there's a way around having to pay the cartels
Did you find a solution. I'm about to renew my certificate for 3 years, it's $100 more per year than I paid a year ago! I just found a coupon code that gives me $100 which is nice. Oh yeah and I have to get a new dongle each time I renew, and just chuck away the old one, what a waste!
Edit: I just scrolled up and re-discovered your detailed post about self signing :)
-
@aaronventure use Inno Setup 5.2.3 (you'll need to adapt the script to that older version)
-
@d-healey I did turn to JUCE and managed to create a semi working app
You compile this baby ONCE, then you just ship it with any plugin. The delivery is a zip containing:
- Installer.exe
- Plugins.dat (essnetially a zip file renamed to dat, you can automate the creation of this for any project using a simple script
- Config.dat
- Samples.dat
The installer first checks if there is Config.dat and if not, throws an error. The Config.dat contains two things: info.json and optionally, background.png. If it contains background.png, it dynamically sets that as the background for the installer GUI. It's all streamed from the archive files, nothing is ever unzipped.
Info.json is a simple JSON object with Product name, company name and version. It uses the names to set the name of the window as you can see and to set the default path for the installing process. After you select a directory, it always appends the product name to the path.
It only shows the path selection Samples.dat exists.
It then extracts the Samples.dat to the target directory.
This app is meant to achieve several things:
Compile and sign once, then forget about it
For delivering plugins or sample libraries in the standard HISE format, it's all you'll ever need. No need to sign anything anymore. Other than AAX maybe.
I need to implement
xattr -cfor mac so you don't have to sign VST or AU anymore either.After that, no more signing EVER. Ideally I'd have this app signed on Win and Mac and everyone can use that signed .exe.
Super easy delivery
You can fully automate the packaging on a single main system using scripts. If the other OS' build to the same networked directory, then once it's done you just run a packaging script which simply zips up the binaries and all relevant files.
One download for all platforms
Easy management of downloads on your hosting service. Save loads of space for large sample libraries without your delivery looking funky and requesting the user manually unzip the samples somewhere
First time dabbling with JUCE to create a functioning app, so the codebase is a mess, but I'll open it up anyway so others can contribute as well. Ideally I hope to have this ready for the launch of my first HISE plugin.
-
I did turn to JUCE and managed to create a semi working app
NOOOO! Why didn't you wait a few weeks, I'm currently building an installer IDE that you can use to create compiled installers (actually your topic here nudged me into that direction).
How are you distributing the many files on Windows? on macOS you can simply put them all in a DMG and get away with it, but there's no thing like this on Windows (except for zipping it all up and let the user expand it but that's a suboptimal workflow IMO).
-
Haha, well, it was good practice. If nothing, I gained immense respect for your work with HISE, as if I didn't have enough already.
Another good thing about this approach is that it enables a fully manual installation just by unzipping the .dat files. For those who want it.
I mean you can do SFX but that's weird, I think everyone by now learned to expect a zip when not using a dedicated downloader.
From what I can see, either you have a downloader app that the user either downloads and runs or installs which then does what I described here, or you ship a self contained zip file right as an order fulfillment.
I don't think delivering zips is an issue at all.
-
@aaronventure said in Inno Setup is Flagged as Trojan?:
You compile this baby ONCE, then you just ship it with any plugin.
Does this get around the smart screen filter?
-
@aaronventure said in Inno Setup is Flagged as Trojan?:
You compile this baby ONCE, then you just ship it with any plugin. The delivery is a zip containing:
Installer.exe
Plugins.dat (essentially a zip file renamed to dat, you can automate the creation of this for any project using a simple script
Config.dat
Samples.datYour problem here is Samples.dat.
Most sample based applications are carrying many Gb of samples with them, so Samples.dat a renamed zip file) will be many Gb big - and as Dave and I have found out thru experience the HISE unzip process can often balk at anything past about 2Gb.... so you are limiting the utility of this right there.
In the end what we did was bite the bullet, and build an installer that:
- knows where in the interwebs your samples are zipped up - Samples01.dat, Samples02.dat... Samples24.dat etc.
- Knows (from its config data - a manifest for us) where these need to go
- downloads these dat files and puts them in the right place.
So this covers downloading too.
The other nice thing about this was it allowed us to add a whole truck load of additional meta-files etc. used by the plugin , e.g. tagging.json etc. - whatever your plugin uses, as well as installing VST3, AU and AAX -plugins across Windows and OSX
So it installs
- plugins (including letting windows users select their VST3 folder)
- samples
- Audio files
- MIDI files
- User Presets
- meta data
- images
etc etc. basically anything you want anywhere you want to put it.
So if you continue with your installer - my experience tells me plugin.dat, samples.dat and config.dat
are not going to be enough.Something for @Christoph to consider too I guess...
-
@aaronventure I would still recommend to go for the DMG option on macOS - you can hide the data files in the DMG folder view and it becomes a very lean user experience.
If you go down this road, I can recommend DMGCanvas, it costs 20 bucks once but is as smooth as it can get (it even automatically notarizes the DMG for you).
@Lindon the installer system I'm working on should cover all bases
- customizable appearance (not 100% skinnable, but you can change some colours and font to match your company's CI)
- ability to download files or do HTTP requests
- Javascript (not HiseScript!) evaluation for doing some simple logic (like hiding some options depending on previous selections)
- inbuilt extraction of HR1 archives and or zip files
- automatically write the sample link file
- (optional) embedding of assets into the installer binary (if you don't want to ship additional files, for FX plugins this should be fine).
I'm switching the main HISE installers to this system for the next release and I think it can be the default option going forward now (the more people use it the more stable it gets obviously).
-
@d-healey If we all use the same .exe, then in a few hundred runs, yes, forever. You don't have to build reputation from 0 for each new release or update of your plugin - the installer.exe is always the same file.
-
@Christoph-Hart How far along the way are you? Do you expect to finish it soon?
-
@aaronventure from what i understand Christoph's system allows us to individually build installers, so they will still be different exe files.
Libre Wave - Freedom respecting instruments and effects
My Patreon - HISE tutorials
YouTube Channel - Public HISE tutorials -
@Christoph-Hart said in Inno Setup is Flagged as Trojan?:
@aaronventure I would still recommend to go for the DMG option on macOS - you can hide the data files in the DMG folder view and it becomes a very lean user experience.
If you go down this road, I can recommend DMGCanvas, it costs 20 bucks once but is as smooth as it can get (it even automatically notarizes the DMG for you).
@Lindon the installer system I'm working on should cover all bases
- customizable appearance (not 100% skinnable, but you can change some colours and font to match your company's CI)
- ability to download files or do HTTP requests
- Javascript (not HiseScript!) evaluation for doing some simple logic (like hiding some options depending on previous selections)
- inbuilt extraction of HR1 archives and or zip files
- automatically write the sample link file
- (optional) embedding of assets into the installer binary (if you don't want to ship additional files, for FX plugins this should be fine).
oh the two features I forgot were:
- The ability to uninstall a product
- The ability to delete the downloaded archives when complete.
-
@Christoph-Hart said in Inno Setup is Flagged as Trojan?:
NOOOO! Why didn't you wait a few weeks
Maybe now is a good time to create an upcoming features roadmap ;)
-
@d-healey said in Inno Setup is Flagged as Trojan?:
from what i understand Christoph's system allows us to individually build installers, so they will still be different exe files.
It could be used to create one installer with a dynamic payload though, so if that keeps 80% of the people from having to throw money into the greedy mouths of Comodo et al, I'm happy to go full Robin Hood on this one.
How far along the way are you? Do you expect to finish it soon?
It's already in the codebase so you can play around with it. Just build the
tools/multipagecreatorapp. There's a introduction project that kind of shows the most important functions available hereHISE/tools/json_dialog/introduction/introduction.json at develop · christophhart/HISE
The open source framework for sample based instruments - HISE/tools/json_dialog/introduction/introduction.json at develop · christophhart/HISE
GitHub (github.com)
Just choose File -> Load and select this JSON file, then click through the project. It's definitely not production ready and needs one or maybe five iterations of UX improvements, but the main concepts are working and I think at this point some feedback would be helpful for me how to polish this bad boy.
The ability to delete the downloaded archives when complete.
Yup, that's a flag in the UnzipAction that you can tick, then it will delete the Zip file after successful extraction (you can also choose to use a temporary file for the download target, then it will also delete it when done).
The ability to uninstall a product
Yes that's a valid request. I haven't implemented this yet, but it's definitely within the scope of that system.
-
checking it now.
Here's a Windows Build.bat file that you can add to the multipagecreator directory for one click build
@echo off set "script_dir=%~dp0" set "projucer_path=..\projucer\Projucer.exe" set "msbuild=C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\MsBuild.exe" REM Echo the paths to verify echo HISE Source directory: %hise_source% echo Projucer Path: %projucer_path% REM Build "%projucer_path%" --resave "multipagecreator.jucer" "%msbuild%" "Builds\VisualStudio2022\multipagecreator.sln" /t:Rebuild /p:Configuration="Release" /verbosity:minimal pause -
@Lindon said in Inno Setup is Flagged as Trojan?:
Your problem here is Samples.dat.
Most sample based applications are carrying many Gb of samples with them, so Samples.dat a renamed zip file) will be many Gb big - and as Dave and I have found out thru experience the HISE unzip process can often balk at anything past about 2Gb.... so you are limiting the utility of this right there.
To address this:
yes, unzip is 32 bit, and still the only native choice in the latest JUCE version.
My app actually makes a list of all the .dat files with Samples in their name, then extracts them one by one.
As ZIP does not support archive splitting, I wrote batch that you can include in the root of your project and it will automatically pack all your chx files into incrementally named zips and keep fitting them. If a new chx monolith would push the archive over 2 GB, it writes it to another archive instead.
@Christoph-Hart said in Inno Setup is Flagged as Trojan?:
would still recommend to go for the DMG option on macOS - you can hide the data files in the DMG folder view and it becomes a very lean user experience.
Well, technically it's the same for Windows ISO files and autorun on mount. NI used to roll like this for a long time if I remember correctly, before Native Access was a thing.
-
@Christoph-Hart said in Inno Setup is Flagged as Trojan?:
Yup, that's a flag in the UnzipAction that you can tick, then it will delete the Zip file after successful extraction (you can also choose to use a temporary file for the download target, then it will also delete it when done).
Actually thats useful - but its not what ours does...it (at a later date) allows the user to un-install the plugin and all its files....so it removes the vst3, au, aax plugins and all the samples in the samples folder(that belong to this product) and the contents of AppData....
