Hi Alaska,

The following are some issues and problems with the Workbench Update Manager 
that I have encountered:

1) The Workbench Update Manager can't be opened without a connection to the 
   Alaska Update/Activation Server, either due to a lack of Internet access 
   or because the Alaska server is down or unreachable. This prevents the 
   user from switching versions or even seeing what versions are available,
   unless an Internet connection to the Alaska Update/Activation Server can 
   be established.

2) The Workbench Update Manager has only a single "Download and Install" 
   button, rather than separate buttons for those two features. If a user 
   wants to download (an older) version, but not actually install it (at 
   the time of download), then that isn't currently possible.

3) On the "Installation History", the single button is also labeled as: 
   "Download and Install", even though those builds were already downloaded 
   and only need to be Installed.

4) Because the only way to switch between versions -- through the Workbench 
   Update Manager -- is to totally uninstall the current/active version and 
   then to install a different version, selecting the MSI's "Cancel" button 
   might completely destroy the existing installation -- depending on when 
   in the process the button is pressed -- leaving the user without a 
   working development environment.

   A "normal" user -- one of those that needs to be protected by Alaska from 
   installing the application where ever they like -- would be completely 
   lost at that point, unable to run the Workbench or its Update Manager to 
   fix the installation. As the location of the MSI files isn't officially 
   documented, (novice) users might have no choice but to contact Alaska 
   support for help.

5) Each change of version takes in excess of 30 minutes, because of the 
   verbose log file that is created and because the entire existing Xbase++ 
   development environment is first uninstalled only to be re-installed in 
   the same location.

Please consider the following requests:

1) Let the user install the application where ever they like, supporting 
   parallel installations of different versions right out of the box. All 
   the specifics about each installation could be easily saved in the 
   "product.config" file, requiring only small changes to the current 
   installation and update process.

2) Add separate "Download" and "Install" buttons for each build in the 
   Update Manager, so users can select each of those features separately.

3) Consider supplying incremental updates for new builds, if they are 
   principally compatible with the existing version of Xbase++, similar to 
   the HotFix Rollups. Use the Minor Version Number to ensure compatibility 
   between builds and to determine if a full install is necessary or not.

4) Document which individual files have been changed between each Build, 
   specifically: Source Code files, Header files, Runtime DLLs.

   Also document if a new build will require new versions of add-on products 
   that do not come with source code, such as Xb2Net, SQLExpress, etc. or if 
   they are runtime-compatible with the previous build(s).

5) Do not create a verbose Log file for each uninstall/install, to make the 
   (update) process much faster.

6) Do not delete any files that weren't installed by your installation 
   process or have been updated since. For (common) DLLs, use the existing 
   Version information in those files to not overwrite newer version files.

7) Consider updating the Open Source DLLs, such as Open SSL, MIT Kerberos, 
   GNU Text Utilities, Microsoft Visual C runtimes, Terra Informatica 
   HTMLayout DLL, and PostGre SQL, when newer versions of the files are 
   available. Otherwise, don't replace newer versions of the files, if they 
   exist. The same is true for the OCX/Active-X files that come with the 
   installation (and which aren't installed by default).

8) Allow the user to open the "Update Manager", even if ASGet.exe returns 
   an error of some sort.

For everyone who would like to do just that -- open the "Update Manager" of 
the Workbench, no matter if the Alaska server is reachable or not -- I have 
attached a small "ASGetProxy" program. This program requires Xb2Net as well 
as ASINet and is just a quick little hack to allow the Workbench to open 
the Update Manager under any circumstances.

If Alaska fixes the Update Manager, so it comes up even if the ASGet.exe 
program returns an error, then this "ASGetProxy" program will no longer be 
necessary.

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
web:   http://www.Aerospace-History.net