InstallAware

Probalby a misnamed topic, but I'm spinnning between which combinations of these options are the right way to go. We have two scenarios that we want to accomplish. I would like someone to indicate which install approaches should be used for each scenario, and yes... I'm willing to hire someone to define or implement these approaches.

Scenario 1: Full applications.

• We build three applications, each of which has about 90% of the application comprised of "common" core components, third party components, microsoft components, etc. We need three separate installation/update processes, all dealing with the same common components.
  
  We must build a complete install CD that has no interenet dependencies.
  
  We typically do an annual upgrade, which much be installed from CD, quarterly updates which are sufficient to update the annual release, w/o the need to go through each prior update, and patches which are only applicable to to the most recent update.
  
  The updates and patches must be accessible from the web.
  
  An update CD is sent to each customer for those customers that can't download updates and patches from the web.
  
  No update/patch process can require a user to find their prior CD, or know anything about where required files might be on their computers.
  
  Updates/Patches are always compatible with prior components. It does not seem necessary to uninstall the application being updated in order to update it.

Scenario 2: "Printer driver" package

• We support the ag industry with a set of plug-in "drivers" that translate proprietary machinery data formats into a single common format. This solution involves a set of core components that are used by client applications for common access, and an increasingly large number of plugin drivers, with each driver supporting the data transformation for one specific brand of farm equipment.
  
  The core components and some of the drivers are distributed by other software vendors as part of their install. Each is currently bundled as a Wise .exe and the other vendors just run them in silent mode. They should probably be converted to merge modules?
  
  The drivers are updated frequently, as farm machinery is updated. We need a single access point for a farmer that is using our application or any other vendors application to go to the web and update the core components and any drivers that they have installed (or install new ones).
  
  There is no required CD distribution of these components.
  
  An update of the core components or any of the drivers should not give the impression of doing an uninstall.

We have built and deployed an install for the first application in Scenario 1. I think we created 15 web media blocks, but compiled as a single compressed exe. We are happy with the initial user experience. We are not happy when we make a very minor change to a component and build a new install, that the appliction is first uninstalled on the target machine before it is updated. Does a patch solve this? But a patch won't work because we installed from a single compressed exe, requiring the user to know the location of the install? Do updates resolve this?

Suggestions or proposals welcome.

There are a couple core misunderstandings which I will address here:

1. It is possible to prevent the "impression" of uninstalling, even when that happens, using clever scripting in MSIcode. Its just a matter of making the uninstall step part of the main install step. You just move your script lines around.

2. If you want to save and reload settings (such as install locations, other script variables) you can do that as well during an auto-uninstall and re-install upgrade cycle.

3. If you simply do not want to uninstall anything, you will want to use patches in that scenario.

4. Using a web build does not mean you have to deploy anything on the web. Web builds can be monolithic (i.e. contain everything in a single file) just like single file builds, and they will then never require access to the web at any time; the difference being that they will locally cache installation sources.

5. If you want to patch installs on the field with automatic source resolution, you want to use web builds. If you want to in addition to that to ship all the installer files on a CD, you can still do that with web builds - just don't define any online web media block in your setup.

In addition to the above, you can probably eliminate a lot of your setup development overhead by using compiler variables. Since all your setups share a common base, you could create one project to comprise that common base, and then conditionally include/exclude the other 10% on top of that at build time (or even, at runtime).

If you would like further discussion of this as a consulting project, please email sales and request a consulting project scope.

In other threads, you have indicated that a single compressed exe does not work well with patches... the user must find the location of the source install, etc.

Is an install based upon offline web media blocks, compiled as a web install, different than a single compressed exe, built using those same media blocks? I'm starting to think it might be? And mabe that is where some of my confusion is. Both solutions create a single exe, but the latter is considered a web install, so the media blocks are cached, and patching works?

Both solutions create a single exe, but the latter is considered a web install,
so the media blocks are cached, and patching works?

Yes - the local caching is the main difference here.

To make a web media build that has the blocks available for downloading, I would need to make two builds... one with the filenames blank to create a single exe with offline blocks, and one with the filenames populated, to create a small core exe and all of the optionally required files.

And, in the latter case, I can put all of these files onto a CD, and InstallAware will first look locally for them, if needed, and secondarily look to the web. So in this case, I could create a single project, deploying on CD and deploying over the web, and the patch process would work in either situation?

That is correct, but be sure to include both builds as patch references, because when you build the two separate versions, the layout of setup files will be different on disk, and the patch needs to be able to know about both to accommodate both.