Will MSI Work For Us?

[webwolve]

Hello,

My company is researching now whether or not we should migrate from an InstallScript based suite of installations to an MSI-based suite. We understand the benefits, yet given our customer expectations and typical uses, we’re not sure how or if to proceed. As I’ll explain, we are far from restricting the end user from running this a single time on a machine in a specified directory.

Over the years, our customers tend to demand that we allow them to install both the same version and multiple versions in multiple folders. For example, a typical customer may run production software in a folder called c:\production. When we ship them a software update, they may install this into c:\test and run through a series of test scenarios to determine if this upgrade is meaningful for them. If all seems well to them, they will then run the install to upgrade their production folder. We don’t currently use the minor upgrade/major upgrade stuff in InstallScript. We just allow customers to run whenever and wherever they choose.

In addition, some customers prefer to keep all previous installs on their machine as well to be able to run multiple versions whenever necessary. So, a customer may have folders called c:\xxx50 and c:\xxx51 and c:\xxx52, etc. It’s just the nature of the business we are in.

Bottom line, we currently allow all of our dozen or so installs be installed and functional in these multiple folders at the same time.

So, when studying MSI for the first time over the past week or so, we’ve quickly realized that this seems against the MSI rules. MSI seems to only support installing a single application version into a single folder. That is, if we ship a customer version 5.0, they cannot install that version in both c:\50A and c:\50B.

I was also asked to research running small MSI installs from within our current large InstallScript package. Doing this pretty well confirmed the issue above. Running msiexec from within InstallScript code worked fine the first time through. As expected, when running it a second time in a different folder, the files dropped at MSI time were placed in the initial install folder rather than the current folder.

Lastly, we unfortunately release and re-release many occurrences of each version. For example, we may release 10 different 5.0 builds to customers. Thus, the customers (possibly in the thousands) may have any or all of them on their machines at any given time. This seems to me that this will be extremely difficult to maintain by MSI as well, especially if we would ever consider using patches and so forth.

All in all, does anyone else deal with similar issues like this, and if so, what do you recommend? Are we facing the ultimate decision of changing how we have always allowed customers to install and run our software? Must we make the choice between running MSI and allowing only one instance of the app on the machine or keeping InstallScript and running business as usual? Is there any way at all we can use MSI and mock our current distribution methods?

Thanks,
WebWolve

[Christopher_Pai]

MSI / InstallShield supports the concept of multiple instance installation. I've used this to deploy SOA SaaS n-Tier .NET applications that are designed for single tenant.

Basically I would deploy multiple instances of the product with differing configuration settings and versions. This applied to the application layer webservice components, the webUI components and the winforms components.

It can be done.

But, realize that MSI is very rigid in what it defines as a major,minor,small upgrade and patch. You have to have discipline and foresite when planning how to deploy and service a product. You can't get away with a lot of the scripting slop that non-MSI script driven installers allow you to do.

[webwolve]

Thanks very much for the response Christopher, and for the links to your blog.

Christopher Painter wrote:
Basically I would deploy multiple instances of the product with differing configuration settings and versions. This applied to the application layer webservice components, the webUI components and the winforms components.

It can be done.

Let me verify if I understand this correctly. What you are saying is that since you cannot run the exact same setup in different folders on a target machine, you modify the Product codes/versions/etc. and essentially create multiple setups containing the same file sets and actions? So, if you have a customer that wants to install in 2 separate folders on the same machine, you send them 2 unique (but similar) setups? Is this what you are saying?

Christopher Painter wrote:
But, realize that MSI is very rigid in what it defines as a major,minor,small upgrade and patch. You have to have discipline and foresite when planning how to deploy and service a product. You can't get away with a lot of the scripting slop that non-MSI script driven installers allow you to do.

One of my personal greatest fears about this is just that, a supreme lack of discipline not from myself, but from those who decide when to build and release our software. We're in a business where it seems we release and re-release each version multiple times, up until we start the process over again when the next version is "ready". It's difficult to manage using InstallScript, so I fear the challenges I'd face in this situation using MSI.

Lastly, from just my testing, I see that if I install my sample setup once, all appears OK in the ARP. If I change the Product Code and Version, rebuild, and run again in the same folder, the folder is updated but an additional ARP is added. It makes sense I suppose, but wouldn't it be best to somehow remove the first entry? Generally, we don't uninstall software before upgrading it. We have many user files to be wary of, so we just run new installs over existing ones and allow the file overwrite properties to work as defined.

Again, appreciate the help very much in these nervous times.
WebWolve

[Christopher_Pai]

Checkout

http://blog.deploymentengineering.com/2006/10/multiple-instance-msis-and.html

Also follow all the various links, that'll explain a lot.