AutoUpdate has been written so that all installed instance of VisitorRego are at the latest version. It was written due to the large amount of work involved in manually updating a single VR Appliance. As the custom base has grown and continues to grow the need to have an automated process of updating has become imperative to the future growth of the company.
The concept is that VisitorRego is not started directly but the program AutoUpdate is started instead of. This is because VisitorRego run time modules can't be updated in situ while VisitorRego is running. AutoUpdate is started and access the VisitorRego run time files on the Ayone FTP server, compares the modified date of the file on the FTP server with it's corresponding file on the VR Appliance. If they are different, then the file on the ftp server is copied and overwriting the file on the VR Appliance. Once all files have been checked then VisitorRego is started automatically by AutoUpdate.
The have been a number of iterations in the development of AutoUpdate, in short, it is not a trivial task. For documentation the following are the major road blocks faced.
1. Running automatically the VisitorRego.msi using /i and /u (install/uninstall switch). Good in theory but impossible to control. Learnt that the whole install process didn't require an .msi. That the whole process can be managed at an individual file level.
2. Developing and testing worked perfectly using FTP. However implementing into customers proved to be impossible. FTP sends the command over port 21 but the reply comes across any random port that we don't have any control over. The more network links, the more isp's the packages have to transfer the more problematic the process be become. In reality it didn't work to any site outside of Auckland. i.e. FTP wasn't a workable solution.
3. Moved AutoUpdate from FTP to WebDav. WebDav uses http to copy files. This has the distinct advantage that no additional ports need to be open. All traffic is across standard http port 80 (and 439 if ssl is implemented). The disadvantage is that WebDav has no concept of directory structure. Any directory needs to exist and we can 'walk' a directory for all files in that directory. At this stage this limits the overall scope of AutoUpdate. At this stage, the scope of AutoUpdate to read for specific files from the Ayone server, compare the modified date of the corresponding file on the VR Appliance and copy if they are different.
Overview of Process
1. On start AutoUpdate determines if it is 32 or 64 bit Windows operating system. From which we determine the default Windows directory that VisitorRego is installed. If it is not the default Windows directory, then this is an issue!
2. Then DBPara.dll is readable. We can determine the current build, the database connection and the type of AutoUpdate (whether WebDav or Mapped drive)
3. If WebDav then the current build is sent to facilities.visitorrego.com server returns the ip address of the Ayone server, the location where the most current visitorrego install set are held, credentials to read these files and the directory on the Ayone server. This allows us to upgrade specific builds.
4. If it's a mapped drive then the the install set resides on a mapped drive on the VisitorRego application server. The purpose of the mapped drive is in large organisations what haven't given us internet access.