Add-on path and updates

[JonnO]

I recently "inherited" a custom add-on developed for our firm.

To make things easier, I remade it using the CMake template, so that is what I'm using today.

The first iteration of the add-on is ready for distribution, but I want to understand if there are better options than placing it in the standard add-ons folder.

The problem is:

Users need to activate 1h of admin privileges to run the installer since it copies to Program Files.

1a. To avoid this, I would like to install the *.apx to an %appdata% folder, where admin is not required.

1b. To "auto" detect the add-on, I was thinking that I could add the registry path for "lan.flat:///[AppDataFolder]/path/to/addon.apx". But I'm having trouble making the logic for finding the first available keyname (i.e. "#1." or next available if custom add-ons have been added by the user before).

I'm using WiX to build the installer.

Are there better solutions for setting up add-ons with custom paths that don't require admin privileges?

Updating the add-on:

2a. Is it possible to have the add-on look for updates on startup, pull a new .apx from git so it is loaded the next time the user restarts AC?

2b. Or are there other solutions for automatically updating the add-on?

[BerndSchwarzenbacher]

Hi JonnO,

Just a few not very fleshed out thoughts to your questions/comments:

1. You could also move the existing Add-On directory to the %appdata% folder, add your add-on and use this path as the default path for all add-ons. Depends of course if that's something your firm wants to do in general.

2a. There's no existing functionality to easily use, but I think it's possible. Depends a lot though on how easily unloadable your Add-On is. E.g. for Add-Ons which immediately unload after finishing their processing, you could start a separate process/executable (not a child of the Add-On/Archicad process) which does the download and overwrites the add-on. Just a rough idea.

Hope that helps,

Bernd

[JonnO]

Thank you, Bernd!

I have actually been able to implement the logic I described for the "#[n]." registry keys after posting. My solution was using a bundled PowerShell script for checking current slots and writing to the available slot (or not add anything if it exists). As long as it works for all our users, I think this solves my first problem.

Updates: if I understand your comment correctly, the .apx cannot be replaced while loaded in AC? (I have not tested/thought of that, but this would be similar to Revit .dlls, which is what I'm used to developing.) I don't need the update to apply immediately, as long as it loads the updated add-on the next time the user restarts AC.

I found a post noting that the .apx can be renamed to .old, might be a solution.

Thank you for your thoughts and suggestions. I will do some testing and see if I can find a solution.

[Akos Somorjai]

Hi Jonn,

To be on the safe side it is better to ask the user to restart Archicad after updating the add-on, as Bernd suggested.

Best,

Akos

[BerndSchwarzenbacher]

Jonn,

I agree with Akos here to stay on the safe side and ask to restart Archicad.

There might be a possibility to do it without a restart. But it's a lot more involved and depends on the specifics of your Add-On.
To clarify .apx are also .dll files (I think with a few extra requirements on top). So if Archicad itself unloads the .apx file, then you can replace it before its loaded again.

Not sure what renaming it to .old would achieve. Maybe you can link the post you've found.

Best regards,
Bernd

[JonnO]

Thank you both for your replies!

I found quite quickly that unloading and updating the .apx was too much hassle. So having the user restart AC to load changes was the plan from the beginning.
For reference, this was the post where they talked about renaming the .apx while loaded, to replace it with a new one for next restart:
https://community.graphisoft.com/t5/Archicad-C-API/Is-there-a-way-for-an-addon-to-unload-itself/m-p/...

The solution I am going with is a separate desktop app I made, that I bundle with the add-on installer. It runs in the background and compares the installed version of the add-on with the latest version on DevOps. I have not decided if I'm going to pull the latest .apx from repo or fetch the latest .msi. It currently downloads and runs the .msi when the user starts the update from the app, since it also updates the version number out of the box. So the update problem is solved, as long as it works in deployment. 🤞

(The bonus is that the same app can also be used for maintaining updates for our Revit plugin and the Revit-IFC versions from Github, that we did not have a solid solution for before. 😊)