This topic should share my existing work on an MSI package which can be used, for example, to distribute Syncthing easily in Windows Domain Environments or to give friends an “easy to install and connect to your server” setup experience.
As I guess every Syncthing user has other demands when it comes to Syncthing’s configuration. For example, some users may like relaying and global discovery and others like to strictly use static IP connections or local site connections only. For that reason, I’ve put everything into BATCH files. If you need to “BUILD YOUR OWN”, just change the port numbers and/or xml setting lines in the batch to fit your needs :-).
The build script I’m personally using to bundle Syncthing into a MSI already “lives” for a long time. I’ve now decided to improve it to reproducibly build with “live-downloaded” packages instead of statically distributing my local set of build (portable EXE) tools. This should also head forward if later someone like to integrate the script into an official Syncthing build server.
I’ll now showcase where to find the MSI build script and how to use it.
Starting Syncthing under Windows I has so far been done by the task planner. However, this does not always work perfectly. It rarely happens that Syncthing does not start and after a long period of running of the computer it could happen that Syncthing no longer ran. This happened repeatedly, especially after an energy-saving mode.
The MSI package is therefore installed on my Windows computers. It has been running perfectly so far. In addition, a service is stored that can be stopped and adjusted. “Local service” is stored by default as the user account, and directory rights are to be assigned to this user.
In my case, I saved the user account as in the task planner and took over the AppData completely from the previous installaion. After the service starts, Syncthing run as before.
Also good work that MSI!
However, that means with the MSI package, as with the SPK package for Synology, that any new updated MSI must be installed when the version changes, since updates are no longer permitted via the GUI. But it means also, that the installation of RCs is officially not possible. I think in the whole it’s a clean solution.
I made this modifikation with Orca and remove in the MSI the rows about STNOUPGRADE in property and registry and try a very new installation, but without effect.
What is the behavior when updating via an MSI package? Is it safe to simply install the new MSI over the current installation without losts or other modifications?
The installation of the MSI with standard parameters the auto upgrade is not possible. It was not possible to change back, if needed, also after modification of the Registry. Also after Deinstallation without deleting of the settings and database and new Installation of MSI with the modified MSI package there was no change.
In which way I change such parameters (activate auto upgrade) after the installation?
In my case this was only possible to set with the modified MSI package and a very green installation.
Exactly that work not for me. I dont know why, the difference is, that I use after the installation my old dataset from the “normal” installation, it means done without MSI.
It could at least explain the behavior as observed. Nevertheless, it would not be entirely plausible because after the installation I exchanged the complete settings directory together with the database for the previous version in which the automatic upgrade was activated.
That’s why I came across the registry, as it was independent of it. But it also seems to me that there are other entries of STNOUPGRADE besides
I don’t know if they have any influence. However, it appears to be typically backup entries from Windows.
Maybe you could do it differently. By definition, an MSI is an installer package with no optional features. Wouldn’t it make more sense to make an EXE in which various installation options can be selected?
The database records the schema version and minimum version required to open it, as Catfriend1 guessed. It does not store anything at all related to enabling or disabling upgrades.
First time I installed a modified version of MSI, that the package can run internal updates. If I install a newer version of MSI, such settings are lost or not?
as an “internal” feature to be platform independent. I have similar issues with Linux Mint and my Synology servers. Would that be possible to implement?
