Installer permissions ...again
-
So I'm updating and modifying my installer program, and two questions:
-
I recall there's a setting/flag I can set to make the windows installer run as administrator, but for the life of me I cant recall what it is...any hints?
-
I also recall there's a process to make the Mac version capable of installing in ~Library/Audio/Plug-Ins rather than ~/User/Library/Audio/Plug-Ins, something about sandboxing the product - I think I did it once and foolishly failed to write down what I did, again any hints?
-
-
-
@d-healey said in Installer permissions ...again:
Well, the first of these I have set already - and its not working....
...and the second is about where the HISE built product puts its APPDATA stuff - not about allowing access to the ~/Library/Audio/Plug-Ins folder structure.....
-
@Lindon said in Installer permissions ...again:
Well, the first of these I have set already - and its not working....
Standalone build?
-
@d-healey said in Installer permissions ...again:
@Lindon said in Installer permissions ...again:
Well, the first of these I have set already - and its not working....
Standalone build?
Yep - but I just finished a rebuild having cleaned the build folder and that is working now, So now just to get write access to
~/Library/Audio/Plug-Ins on the mac.... -
I think I found it..
https://forum.hise.audio/topic/8251/back-to-the-mac-installer-tweaking/5 -
@Lindon but its still not clear what I need to set in here to get to the folders I need - I dont thing "Music" is it....
Has anyone got to the point of being able to write to ~/Library/Audio/Plug-Ins on the Mac???
-
@Lindon yes i am able to write to ~/Library/Audio/Plug-Ins. the flag in Hise just determines where the AppData folder goes (its called ApplicationData on Mac) and the installer you create determines where the vst files go. hope that helps.
-
@Adam_G said in Installer permissions ...again:
@Lindon yes i am able to write to ~/Library/Audio/Plug-Ins. the flag in Hise just determines where the AppData folder goes (its called ApplicationData on Mac) and the installer you create determines where the vst files go. hope that helps.
Okay great - so your installer written in HISE (not packages etc.) it installs in ~/Library ???
If so how did you set up HISE flags for this?
-
@Lindon When you access the AppData folder and write a link file, for example, that's also in ~/Library...
Could you just go up the parent directories and then back down the other fork into the VST3 / Components folder using the FileSystem APIs?
-
@DanH said in Installer permissions ...again:
@Lindon When you access the AppData folder and write a link file, for example, that's also in ~/Library...
I think you might find that its not... its in: ~/Users/username/Library/Application Support/...... unless you set the globals flag for this -- which doesn't help any here.
Could you just go up the parent directories and then back down the other fork into the VST3 / Components folder using the FileSystem APIs?
I have no problem getting the path - I just dont have write permission to this folder:
~/Library/Audio/Plug-Ins
-
@Lindon ah yeah, ok. I've had numerous permissions issues since upgrading to Sonoma with other software as well as HISE - did a lot of manually changing folder permissions and giving programs disk access etc. Always an uphill battle - and then more issues when they release another OSX update!
Are there examples of other devs using an app to install the plugin files?
-
@DanH said in Installer permissions ...again:
Are there examples of other devs using an app to install the plugin files?
Well it's clearly possible WhiteBox Packages build a .pkg file that does it - as do other installers, but looking thru the JUCE forums it seems its a not-uncommon problem, with only ugly work arounds.
-
@DanH I just build a installer for MacOS that installs the VST3 and the AU into the System Root and the Samples and LinkOSX file into the ~/Library/Application support.
Since the Whitebox Packages Installer can only install into either home or the root you will need to choose root directory and then run a post install script to move the files to the home directory.
Here is my script. That will also setup the LinkOSX file for the sample location so that you open up the Plugin and have it work right away without installing Samples. I had no permission errors with that approach since.
#!/bin/sh # Write sample location selected by user to LinkOSX for HISE # First, remove LinkOSX file if it's already there instrumentname="InstrumentName" devname="Company Name" mv /Library/Application\ Support/CompanyName ~/Library/Application\ Support/ FILE="$HOME/Library/Application Support/${devname}/${instrumentname}/LinkOSX" if test -n "$FILE"; then rm -R "$HOME/Library/Application Support/${devname}/${instrumentname}/LinkOSX" fi # Second, use the environment variable from WhiteBox Packages to write the destination to a file destfile=/Users/${USER}/Library/Application\ Support/${devname}/${instrumentname}/LinkOSX printf "/Users/${USER}/Library/Application Support/${devname}/${instrumentname}/Samples" > "$destfile"
-
@oskarsh said in Installer permissions ...again:
@DanH I just build a installer for MacOS that installs the VST3 and the AU into the System Root and the Samples and LinkOSX file into the ~/Library/Application support.
Since the Whitebox Packages Installer can only install into either home or the root you will need to choose root directory and then run a post install script to move the files to the home directory.
Here is my script. That will also setup the LinkOSX file for the sample location so that you open up the Plugin and have it work right away without installing Samples. I had no permission errors with that approach since.
#!/bin/sh # Write sample location selected by user to LinkOSX for HISE # First, remove LinkOSX file if it's already there instrumentname="InstrumentName" devname="Company Name" mv /Library/Application\ Support/CompanyName ~/Library/Application\ Support/ FILE="$HOME/Library/Application Support/${devname}/${instrumentname}/LinkOSX" if test -n "$FILE"; then rm -R "$HOME/Library/Application Support/${devname}/${instrumentname}/LinkOSX" fi # Second, use the environment variable from WhiteBox Packages to write the destination to a file destfile=/Users/${USER}/Library/Application\ Support/${devname}/${instrumentname}/LinkOSX printf "${DSTROOT}/Library/Application Support/${devname}/${instrumentname}/Samples" > "$destfile"
This is an interesting approach - do you think there is a way to write a script that would copy a plugin from say:
~/Users/<username>/Library/Audio/Plug-Ins/VST3/some.vst3
to:
~/Library/Audio/Plug-Ins/VST3/some.vst3-- then somehow run this from within the HISE installer at the end...
-
@oskarsh Yup I do the same, just wondering about an app that isn't Whitebox Packages being able to install the plugin files.
-
@DanH said in Installer permissions ...again:
Are there examples of other devs using an app to install the plugin files?
I do it with Rhapsody, but I use the user library folder.
-
@Lindon I don't think moving the files will be an issue. As for running the installer from within HISE I don't know, but presumably it will bring up the Packages installer process etc when run.
-
I think you guys are misunderstanding what Lindon is trying to do. He's trying to make an app that puts files in the Library folder. He's not using an installer program like Packages.
@Lindon
startAsProcess
can launch an external program (and presumably a script). There is also asetExecutePermission
function that might be helpful here. -
@DanH said in Installer permissions ...again:
@Lindon I don't think moving the files will be an issue. As for running the installer from within HISE I don't know, but presumably it will bring up the Packages installer process etc when run.
no, I dont mean to run Packages at all - I dont use PAckages any more...
So
- Run the HISE-based installer, it writes the VST3 to the User folder structure
- run a shell script (from within the HISE installer) to copy the vst3 to the System folder...so I assume this is File.startAsProcess(String parameters);
See that assumption right there? Often a bad thing...
Now the plugin is in both places (best outcome).