Hints for developers

Requirements

1. Take into account that instances of Altaxo may be running on the same computer from the same user or from different users, and may be running on different computers (via network).

2. Take into account that instances of the Updater may be running on the same computer from the same user or from different users, and even on different computers

This results in:

1. no Altaxo instance must be executing from the directory, which should be updated

2. instances of Altaxo from other directories may be running on this computer or on other computers

3. it must be possible to detect if instances of Altaxo are running on other computers (via network) from the directory to update

4. Lock mechanism: only one instance of the updater should be running for one Altaxo directory. The updater instances may be running on the same computer or on other computers.

5. Elevated privileges: the request for elevated privileges should be issued only when an Altaxo update is possible (see below).

Detection of the moment when it is possible to update Altaxo

1. Try to open all .exe files and all .chm files in exclusive write mode

2. If this succeeds, try to open and close all other files in write mode

3. If this succeeds, it is possible to update Altaxo. Elevated privileges may be necessary to update Altaxo.

Locking of updater instances

1. if possible (no elevated privileges required), create a lock file in the installation directory. This prevents instances on the same computer or on other computers to run simultaneously.

2. If using a lock file is not possible, create a semaphore. This prevents at least instances of the updater on the same computer from running simultaneously.

Updating process

1. The updater starts with normal privileges and ensures that no other instance of the updater is running for the directory-to-update. If it detects that another instance is running, it immediately ends itself. It then locks the directory-to-update.

2. The updater creates a temporary directory, and makes a safety copy of the directory-to-update

3. The updater creates a 2nd temporary directory, and unpacks the new installation files in this directory. It then copies the files from the existing installation that are not on the packing list, or are modified with respect to the packing list.

4. The updater detects (in a loop) the moment when it is possible to update (see above).

5. The updater detects if elevated privileges are required, and requests those.

6. The updater moves files from the directory-to-update to the temporary directory. If any error occurs, it immediately copies the already moved files back to the directory-to-update, and then ends itself.

7. The updater moves the new files to the directory-to-update. If any error occurs, the user must be informed that the old installation directory still exists, and where it is to find.

8. The updater removes the temporary directories.

The AddIn node (Level 1)

The AddIn node is the root node of the addin.

The StringResources node (Level 2, parent AddIn)

The StringResources node contains an attribute only: file, which designates the location of a .resources file (relative to the location of the .addin file) which contains common string resources for the addin.

The BitmapResources node (Level 2, parent AddIn)

The BitmapResources node contains an attribute only: file, which designates the location of a .resources file (relative to the location of the .addin file) which contains common bitmap resources for the addin.

The Runtime node (Level 2, parent AddIn)

The runtime node contains one or more import nodes.

The Importnode (Level 3, parent Runtime)

The Import node has an attribute assembly.

The assembly attribute can have one of the following formats (see Altaxo.AddinItems.Runtime.Load()):

• an assembly name starting with : means that the assembly is searched in the GAC and in the directory where the startup assembly is located.

• an assembly name starting with $ should have the following format: $AddinName/AssemblyName. The assembly is searched in the directory where the specified addin file is located (and in subdirectories of it).

• all other assembly names are treated as they are. The assembly is searched beginning in the path where the addin file is located.