Web update and Windows Install

[NewsArchive]

I have a webupdate project that works great. However, some customers do not
have internet access on their servers, and they would like to have a
traditional Windows install instead. Is there a way to use the same project
to compile both flavors? Or is there a better way than maintaining 2
separate setup projects?

Thanks!
-Dave Moyer

[NewsArchive]

Hi Dave,

> I have a webupdate project that works great. However, some customers do
> not have internet access on their servers, and they would like to have a
> traditional Windows install instead. Is there a way to use the same
> project to compile both flavors? Or is there a better way than
> maintaining 2 separate setup projects?

It all depends on your deployment strategy. What we do is, we provide a
full SetupBuilder install image (that can do a new install and a
repair/update in "maintenance mode") and a web update. When a new release
becomes available, our customers can use the full install or web update to
bring their system to the latest build.

Friedrich

[NewsArchive]

Friedrich,
I think part of his question was "how"...

So do you
1. Maintain two separate SB projects (web and standalone) and edit both of
them identically each time you make changes
2. Give each of those the same PRODUCTGUID and UPGRADEGUID
or
3. Switch a single project back and forth between creating a standalone
installer and a web update installer.

Jane

[NewsArchive]

Hi Jane,

> I think part of his question was "how"...
>
> So do you
> 1. Maintain two separate SB projects (web and standalone) and edit both of
> them identically each time you make changes
> 2. Give each of those the same PRODUCTGUID and UPGRADEGUID
> or
> 3. Switch a single project back and forth between creating a standalone
> installer and a web update installer.

The "how" depends on the product and the individual deployment strategy.

I have two separate projects: one FULL install .sb7 and one WEBINSTALL .sb7.
Same PRODUCTGUID, UPGRADEGUID and Uninstall .exe/.log names.

If the FULL install detects an already installed application, it
automatically switches into "maintenance mode" to handle the update/repair
scenario. If the installed version is older than the version included in
the setup.exe then it UPDATES the system. If the installed version is equal
to the version included in the setup.exe then it executes a file REPAIR
process (installs missing files, updates older files, does not touch equal
or newer files). If the installed version is never than the version
included in the setup.exe then it tells the user that "This setup installs
an earlier version. You will have to uninstall the previous version before
installing this version" and offers an automatic uninstall. In our
deployment strategy, the UPDATE/REPAIR only processes file actions -- it
does not touch the registry, shortcuts, etc. The above
install/update/repair logic is completely script driven.

Our "dynamic" WEBINSTALL installer includes all files that changed between
the initial version and the latest version (e.g. all changed files from SB7
Gold to SB75). The file list is automatically generated by the "Auto Update
Scan" feature.

But there are many different deployment strategies possible. For example,
quite a few developers add all files (including files that never changed
between the initial and the latest version) to a WEBUPDATE because the
"dynamic" web update process is smart enough to download and install only
the data necessary for the installation. Or you can perform Shortcut,
Registry, etc. actions in a REPAIR process. Other developers do a full
uninstall before performing an update. Some developers have a single .sb7
project to compile both FULL and WEBINSTALL apps.

Friedrich