PDA

View Full Version : Repair Chained MSI



steveweaver99
08-11-2014, 03:30 PM
Hi all or IS Developers

Does anyone know if IS 2014 has improved the chained MSI functionality, particularly around repairing?

In previous versions the undocumented value ecoReinstallInstalled had to be set in the ISChainPackage table and then a populated property of RENINSTALL=ALL passed to the chained MSI(s). But the population was conditional based on whether the MSI had previously been installed or not, this would make the use of Chained MSI's somewhat clunky.

I know a few people have had issues surrounding this feature when a repair was involved , it seemed to work in some cases and not others forcing people to look for other alternatives which is a shame as chaining MSI's can be quite useful..

Anyone?

MichaelU
08-14-2014, 08:05 AM
I don't believe we've made any changes to the repair scenarios you're describing. After encountering several issues that made it clear that embedded chainers (the kind you describe) were not as well supported as bootstrap chainers, we've focused our efforts on the latter instead. The InstallShield implementation of a bootstrap chainer is part of the Suite/Advanced UI project type.

steveweaver99
08-17-2014, 06:36 AM
I don't believe we've made any changes to the repair scenarios you're describing. After encountering several issues that made it clear that embedded chainers (the kind you describe) were not as well supported as bootstrap chainers, we've focused our efforts on the latter instead. The InstallShield implementation of a bootstrap chainer is part of the Suite/Advanced UI project type.

Hi Michael

Thanks for the reply.

The bootstrap chainers does not match our requirements, as the boot strap chainer is mainly used for pre-requisites and redistributables. Our requirement is to wrap the msi/vendor msi with our own ISM based from a template, thus using the chained msi feature. This works fine but I don't have much confidence in the repairing of the chained msi's. You could author a custom action that detects if the chained msi(s) have already been installed and is so populate aproperty with for example REINSTALL=ALL and pass it to the chained msi(s), but it starts to get more complicated if there are a series of chained miss and some have been installed and some have not for one reason or another, so you need an authored custom action to accommodate this requirement.

It all starts to get clunky and messy and I have seen it fail in certain scenarios. Would it not be good for Flexera to adapt the chained msi feature to allow a repair of the chained msi seamlessly. So no need to set the ecoreinstalled flag, if a repair of the parent is taken place the chained msi (if installed) would automatically repair too?

Otherwise you may aswell decommission the feature as it is not 'fit for purpose'.

I agree the bootstrap chainer does have it's place and works well for most, but it does not cover all.

MichaelU
08-18-2014, 08:20 AM
Can I ask a bit more about the purpose of your wrapper? It sounds like your wrapper is a means of easing the installation of a group of MSI packages, probably somewhat related, but not necessarily. However you then talk about repairing them, and I'm unclear why you would need to do this. If you are installing a second wrapper that shares packages with a preceding wrapper, then prerequisite-style packages should be in fine condition and can be left alone. If you are encountering a problem with an application and suspect the repair of its dependency would resolve things, are your wrappers the visible entry point in Programs and Features, or is each MSI visible there? Also, why must your wrapper be a MSI? (Since all it can wrap through chained packages are additional MSIs, any system that can only distribute MSI files should be able to distribute the chained packages.)

As an idea towards making things slightly less cumbersome with the current support, you may be able to leverage some of the more esoteric capabilities of Windows Installer's formatting notation (http://msdn.microsoft.com/en-us/library/aa368609.aspx). For example, say you populate a property named REINSTALL_XYZ with the list of features (or ALL) when the XYZ package needs to be reinstalled. Then the command line for package XYZ could include something like ... { REINSTALL="[REINSTALL_XYZ]"} ... which only includes that curly-brace wrapped section if REINSTALL_XYZ is not empty. (I do understand that this does not remove the related difficulties, but it might help minimize them.)

steveweaver99
08-18-2014, 04:42 PM
Can I ask a bit more about the purpose of your wrapper? It sounds like your wrapper is a means of easing the installation of a group of MSI packages, probably somewhat related, but not necessarily. However you then talk about repairing them, and I'm unclear why you would need to do this. If you are installing a second wrapper that shares packages with a preceding wrapper, then prerequisite-style packages should be in fine condition and can be left alone. If you are encountering a problem with an application and suspect the repair of its dependency would resolve things, are your wrappers the visible entry point in Programs and Features, or is each MSI visible there? Also, why must your wrapper be a MSI? (Since all it can wrap through chained packages are additional MSIs, any system that can only distribute MSI files should be able to distribute the chained packages.)

As an idea towards making things slightly less cumbersome with the current support, you may be able to leverage some of the more esoteric capabilities of Windows Installer's formatting notation (http://msdn.microsoft.com/en-us/library/aa368609.aspx). For example, say you populate a property named REINSTALL_XYZ with the list of features (or ALL) when the XYZ package needs to be reinstalled. Then the command line for package XYZ could include something like ... { REINSTALL="[REINSTALL_XYZ]"} ... which only includes that curly-brace wrapped section if REINSTALL_XYZ is not empty. (I do understand that this does not remove the related difficulties, but it might help minimize them.)

Hi Michael

Thanks for the response.

First of all, just to give you an insight into why the requirement of a wrapped set of chained MSI's, MST's, MSP's
From my experience working in both a software house environment and an enterprise environment, I would say the boot strap chainer is more suitable for the bespoke written application where lots of external end users might require a nice experience of being able to deploy the main software, such as a nice user interface handle the installation of the redistributables and pre-requisites. The enterprise business on the other hand, for example might want to deploy software to many internal end users, which will be handled silently (no UI) by a deployment tool such as SCCM.

>>Can I ask a bit more about the purpose of your wrapper?

The wrapper has basically two purposes, one to ease the installation of multiple MSI(s), MST(s), MSP(s) and any other associated files and the second is to include useful information such as installed time and date, author, etc which can also be handy for SCCM auditing.

Many enterprise businesses might use, instead of a wrapper, an MST to brand the vendor MSI(s) and something as crude as a VB script or batch file as a vehicle to install.

>>However you then talk about repairing them, and I'm unclear why you would need to do this.

The wrapper as you mentioned will be the only visible entry point in the ARP applet, as you wouldn't want a duplicate entries for example. So if one did try a repair, unless some mechanism was implemented the repair would fail not for the wrapper but for the chained MSI(s). It might be also plausible that the chained MSI contains some HKEY CURRENT USER registry keys. So in a scenario where we author Active Setup and log on as a different user those keys contained in the chained MSI will not get written because it did not self repair. These are a couple of examples, the bottom line is the chained MSI needs to repair or reinstall itself.

>>If you are installing a second wrapper that shares packages with a preceding wrapper, then prerequisite-style packages should be in fine condition and can be left alone.

This is not relevant at this point in time.

>>Also, why must your wrapper be a MSI? (Since all it can wrap through chained packages are additional MSIs, any system that can only distribute MSI files should be able to distribute the chained packages.)

Using the MSI wrapper is a nice neat solution as opposed to using a VB Script or Powershell or even a deployment tool like SCCM. Why not have an MSI, you could use Installscript, but then this would be less manageable in my opinion.

If the chained MSI feature is there, surely it should be fit for purpose and not require the author to circumvent the feature? Why was ecoreinstalled undocumented? You must of hand quite a few queries regarding repairing the chained MSI? I would also like to say that most of the clients for the Installshield tool are businesses that use it in enterprise environments rather than software house? Now with Wise being EOL, more and more enterprise businesses will be using Installshield.

Your idea to make this less cumbersome is another solution, not one I have experience of, but I guess more work is required to get it to work rather than having a feature built into the chained MSI view?

Thanks

MichaelU
08-19-2014, 08:12 AM
Thanks, that does help clarify; I can take these discussions to product management. I will warn you that, as I said before, our chaining focus is on bootstrap chainers at this point, so I can't make any promises on timeline.

You are absolutely correct that the formatting trick I described is more work than a feature designed specifically to support the repair scenario. However if it does help, it will help in your existing version of InstallShield and won't have to wait for the new feature to become available.

steveweaver99
08-19-2014, 05:39 PM
Thanks, that does help clarify; I can take these discussions to product management. I will warn you that, as I said before, our chaining focus is on bootstrap chainers at this point, so I can't make any promises on timeline.

You are absolutely correct that the formatting trick I described is more work than a feature designed specifically to support the repair scenario. However if it does help, it will help in your existing version of InstallShield and won't have to wait for the new feature to become available.

Hi Michael

Thanks for the response again and for taking on board my comments...

I think it would pay to have this feature implemented as a lot of packaging teams from enterprise type businesses may want to use this, after all a lot are now migrating over to Adminstudio/Installshield and leaving behind Wise. It might also be worth noting that the Installshield product should also try and focus on requirements for packagers and not just installation developers, afterall Installshield does ship with Adminstudio and not just the standalone professional/premier edition, something for the product team to bear in mind.

So for the time being as you mentioned I could implement the solution you provided, albeit more finicky.

Thanks again.