VCSL Project Installer
-
Alright everybody,
as the next step on the roadmap to offering a perfect installer solution for HISE based products, I took the VCSL example project I did a few years ago and created an installer for it with the multipage creator (and DMGCanvas)
https://github.com/christophhart/vcsl_hise/releases/tag/1.0.0
and the description of the process and how to use this as starting point for your own installers:
https://github.com/christophhart/vcsl_hise/tree/master/Installer
It's still not in a phase where I would recommend that other people use it, but we're getting closer. For the next phase I would love to gather some feedback both from an end user perspective (like how the install procedure can be further improved) as well as a developer perspective (how does it fit in your pipeline and what features would you like to see)?
I'm thinking of creating a function in HISE that will spit out the json for the installer dialog so you can have a project based starting point.
Note: the installer is currently macOS only, I'll do the Windows stuff tomorrow.
-
@Christoph-Hart said in VCSL Project Installer:
(like how the install procedure can be further improved)
The popup is unnecessary; the red outline is pretty self explanatory. Other than that it's pretty smooth.
@Christoph-Hart said in VCSL Project Installer:
as well as a developer perspective
100% of plugin installers I used in my life are exactly the same:
- Accept EULA
- Choose plugin types
- If using samples, choose destination
- Click install, click finish.
Unless you're installing a standalone app that ships with some other software, any HISE plugin will be exactly the same, so 99.99% of devs won't need more than what's in that template, they'll just style it.
For a one-click solution that makes HISE output look good for all the users without them ever having to think about this, including those who just started using it, here's an idea:
- On export from HISE (as well as an argument in export from the command line), as whether the product should be packed.
- With the HISE source, ship an .exe installer and an .app installer. If both are signed, it eliminates the need for dealing with that (and essentially eliminates smartscreen as everyone is shipping the same installer.exe), although they'll still need an Apple Developer ID to put it into HISE settings so HISE can sign the VST (unless the installer just runs xattr -c on the .vst3 .aaxplugin and .component files after copying them to target directories)
- use the project name, company name etc from the project_info to create a json file wrapped in config.dat or whatever.
- include a style.css from somewhere in the project folder if anyone wants to use custom styles for the installer
- include the eula from somewhere in the project folder. EULA should be written in markdown (probably)
- if samples are used, collect the used samples (chx monoliths, wavs or hr1), based on samplemap data, into a folder called Company - Project Name, zip it up into Samples.dat
*zip anything else that might need putting inside APPDATA like external images, external impulse responses, presets
The Deploy folder in the project directly now looks like this for each OS:
- Installer.exe/Installer.app
- Plugins.dat
- Config.dat
- Samples.dat (if samples used)
- Data.dat (for appdata)
As the final step of the export, you zip it all up and present a final zip file ready for shipping. So the developer doesn't actually have to do anything, beyond making sure all the data is correct in the project preferences.
On Installer startup:
- read the json on .app or .exe startup to set the app title name and default destinations, styles.css to adjust the style, eula to display the eula
- execute the install
This is essentially my "glorified unzipper" we talked about earlier this year.
That can be the default solution that you offer (like so many other things in HISE). Whoever wants a different experience or more things to do with the installer can easily roll their own using MPC or any other solution.
-
@aaronventure Building a binary that can read a JSON and show the dialog should not be a huge leap from here (it's basically the multipage creator without all the stuff around the dialog. I can then add another option to export which bundles the JSON and all files (EULA, additional CSS plus installer payload) into a single file.
The deal breaking issue for me (still) is that you then have to ship multiple files as the installer which are supposed to be next to each other. It sounds weird, but people will mess this up and you'll get customer support requests that the installer doesn't work. Again, this is only on Windows, on macOS you can throw whatever files you want into the DMG and even hide them so the end user only has a single thing to click.
So basically it boils down to:
- using the workflow of the VCSL installer - actually compiling an installer that can embed all binaries. This requires you to sign the installer yourself
- using the workflow that you suggest. The signing isn't necessary anymore, but you need to make sure that the installer and the JSON metadata blob (as well as the installer payload) will end up next to each other.
I don't see a reason why I shouldn't offer both options, then everyone can decide how to package that up.
-
Alright, I've added a
tools/payload_installerproject to the HISE repo which does exactly that.https://github.com/christophhart/HISE/tree/develop/tools/payload_installer
-
is this a template for creating a package installer for your own plugin?
-
@jeffd no, it's an installer for your own plugin.
-
Oh that’s what I meant.. that’s awesome. When do you expect it to be ready?
-
@Christoph-Hart said in VCSL Project Installer:
The deal breaking issue for me (still) is that you then have to ship multiple files as the installer which are supposed to be next to each other. It sounds weird, but people will mess this up and you'll get customer support requests that the installer doesn't work. Again, this is only on Windows,
But if you're shipping a sample library with over 2GB with Inno Setup, you're getting a bunch of files. A bunch of .bin files and a single .exe file. The idea of it being .dat files is that they're not associated with anything by default, so it'll look like a bunch of blank files and an .exe. But if someone insists, they can just open the .dat files (which are renamed zip files) with an archiver and do a manual install.
Plus, on windows, you can also do an ISO using native windows tools and simply pack in an autorun file which will start the exe on mount, no?
-
@Christoph-Hart I downloaded the VCSL repo, loaded the installer.json into MPC, exported monolith without touching anything, named it PayloadInstaller.dat, put the PayloadInstaller.app in the same directory and it fails to open:
-
Regarding the MPC, here are some preliminary thoughts and observations:
Amazing app and amazing value for the HISE devs. The payload is also great because it's fully customisable.
-
Unzip task could do with a way to group multiple unzips into one progress bar. Maybe a layout element that we can then group unzip tasks into, and its trigger overriding the triggers of the unzips?
-
This should also work for copySiblingFile, commandLine, extractHLAC etc.
-
CopySiblingFile and copyAsset needs a cleanup option, for when using it with the Temp dir. I.e. it needs a move option.
-
Shift+F5 for clear state object. If you move the .json file to a new directory, and load it, relative paths (parent directory) will return the old path until you clear the state object. Doing this should also automatically position the dialog to the first page unless edit mode is enabled. Upon exiting edit mode, it should return the dialog to the first page. Or there should be a checkbox for this, because being down far can be useless unless you're pulling all the necessary variables on that very same page/list.
-
Fail of a required button is a bit wonky, e.g. for the EULA: it shifts the elements by a few pixels, shifts the entire text because it introduces the red X on the side, and the additional popup obscures everything. There should be a property where we can specify the "not selected" popup text, as well as disable it.
-
Spacer seems to lack the height property (or any), although margin-top works on individual components.
-
For subsequent builds (patches, updates etc.) is there a way to trigger a projucer project creation and monolith export from CLI? e.g. multipagecreator.exe -export_monolith -O: "/target/directory/monolithFilename.dat"? This can then be added to a workflow for a single click export of a project from HISE as the .json is already editable and I can just change the version using the terminal to the one in the project_info.xml.
-
-
@aaronventure Thanks for the feedback, it's really at a stage now where I can need some guidance how to proceed and stabilize the procedure.
for 1. and 2. I can imagine adding a coallascated action, which will act as container (like List and columns), but show the total progress of all children in a single process bar. This way it's flexible and not tied to a single action type - so you can also combine different types (eg. download and extract) into a single progress bar.
4 is a good idea (not sure about returning to page 1 when you leave edit mode, but doing so when you clear the state object is definitely helpful, 5. is already on my list - the entire error appearance is customizable with CSS but I think I need to change the default template.
6 the spacer actually precedes the ability to do positioning in CSS so I'll probably remove it again. But you should be able to specify the height of it with an inline style
height: 120px;the command line option is already in there and part of the build script that created the 4.0.0 installer:
It doesn't support monolith export yet, but that should be a no brainer. I'm also thinking about making a wizard (like the Broadcaster Wizard) that will create the installer json from your project_info and some settings and then run everything from inside HISE, once I get a good overview of the generic feature set.
-
@Christoph-Hart said in VCSL Project Installer:
for 1. and 2. I can imagine adding a coallascated action, which will act as container (like List and columns), but show the total progress of all children in a single process bar. This way it's flexible and not tied to a single action type - so you can also combine different types (eg. download and extract) into a single progress bar.
exactly, great!
@Christoph-Hart said in VCSL Project Installer:
4 is a good idea (not sure about returning to page 1 when you leave edit mode, but doing so when you clear the state object is definitely helpful, 5. is already on my list - the entire error appearance is customizable with CSS but I think I need to change the default template.
I meant if you clear a state object while in edit mode. if you think clearing a state object while in edit mode should close edit mode and return you to page one, then sure (I have no true opinion about that particular situation, I just noted it down as a consequence)
@Christoph-Hart said in VCSL Project Installer:
It doesn't support monolith export yet, but that should be a no brainer. I'm also thinking about making a wizard (like the Broadcaster Wizard) that will create the installer json from your project_info and some settings and then run everything from inside HISE, once I get a good overview of the generic feature set.
Sounds like a good thing to do once you've nailed it all down. For now, any power user who's running their own shell script workflows just needs a cli argument to create the monolith file from the input json.
Btw, here's how a finished project with the PayloadInstaller looks like:
This is all in an ISO file created using oscdimg.exe from the Assessment and Deployment Toolkit, so the end user cannot accidentally mess things up and move things somewhere. You can make the iso read-only as well.
It is actually dirt simple to come up with a scheme for deploying files: I have samples in 001, appdata stuff in 002, plugins in 003 etc.
Now the only point of confusion could be the other file named just like the installer. If that were named 000, it would be pretty obvious.
This is exactly what a sample library looks like when you pack it up using Inno setup: one small installer and a bunch of .bin files.
Do you think we can come up with a naming scheme for the install files and that you can then add a string for the PayloadInstaller to search, before searching for its name, so that deployment can look like this?
I can then whip up an ISO creation script with a tutorial that you can put in the repo (oscdimg is a Windows tool).
-
@Christoph-Hart said in VCSL Project Installer:
- is already on my list - the entire error appearance is customizable with CSS but I think I need to change the default template.
I think that there might be a better solution for this particular issue: simply don't have the "Next" button be clickable if there's an unchecked required button on the page.
Also, how do you use a wallpaper/background image? I see a property in Project properties and if I add an asset, then reload, I can select it but it's not showing up anywhere.
Are assets stored in the monolith?
-
This post is deleted! -
I'm really looking forward to this installer, it would help me a lot as I'm having a hard time figuring out what's the best solution for distributing my first product. Using this installer with Hise Activate would be a good solution for deploying my stuff.
-
@Christoph-Hart Allow installations to both user and system directories. Ensure custom app and plugin icons pass notarisation. Account for the current problem plaguing DMGCanvas. Don't reinvent the wheel.
-
@Christoph-Hart I'm dealing with multipage again and the signed binaries are great for quickly testing things out on test systems. The windows one works but the macOS one won't open (see post from June above).
I see you're still working on multipage, can you take a look while you're at it?
The source code for the payload installer isn't huge so I don't think it should be something big, but I'm not versed enough in native macOS development to figure out why it wouldn't be launching.
Thanks.
-
@aaronventure Can you check again? I've recompiled the installer and pushed the new binary.
It's code signed with my developer account but not notarized (as you need to notarize the DMG that you ship the installer and not the installer as is).
-
I assume this has something to do with the commit before the last
- multipagecreator: added version check when loading payload -
@aaronventure yup, feature not a bug, you need to export your monolith with a matching build of the multipage creator so that there are no version mismatches.
