Should Virtual Software Packages (VSPs) include Microsoft Installer Files (MSIs)?
Filed under:
Software Virtualization Solution
Best Practices, Packaging
Submitted by Scott Jones on 28 September, 2007 - 09:09.
Q:
Rob asked, "Should I include the application's source MSI in the Virtual Software Package?"
A:
We usually recommend it, Rob. Placing the source MSI for an application inside the application's Virtual Software Package is necessary for SVS to properly handle various Windows Installer features such as self-healing, install-on-demand, patch installation and upgrades. When the Windows Installer service performs one of these functions, it will access the MSI source. If the MSI source is in the VSP with the app, that is SVS's heads-up that the resultant actions must be kept within the appropriate virtual layer.
For self-healing, it's recommended just in the interest of the best user experience (so they don't see an error box saying the source can't be found). Since of course a reset would undo both the self-healing and the problem that caused it to kick in, ultimately it doesn't really matter. Customers just usually want things to happen invisibly to the end user. Our best practice would be to disable MSI self-healing if Windows Installer allowed that, but it doesn't.
Install-on-demand and Windows Update/Microsoft Update are usually things people want to work, so to support those it's necessary to put the MSI in the layer. These are more important than self-healing.
(26 votes)
- Login or register to post comments
- 3290 reads
- Printer-friendly version
Disable self healing..
I have effectively broken self healing in a couple of my packages in such a way that a self heal never happens and errors never get thrown. This allows you to save the space of the source files and use the reset the way it was made when installing with an MSI. This is not recommened on apps that you would like to upgrade inside the layer. You must take the reg keys under HKLM\Software\Classes\Installer\Products\%GUID%\SourceList out completely. Then remove the sources from your VSP. Someone might know problem with this method but i have not seen a problem with it yet. You just have to know when to use it and when not to.
Well...
...using that method you would also break install-on-demand and patch/upgrade. Install-on-demand probably isn't an issue for most customers, but patch/upgrade certainly is.
Without the MSI source in the layer, to get patches and upgrades properly installed into the application layer (and not to the base), you would need to wrap the update in a script that uses svscmd exec to run the update as if it were part of the app layer. That makes updates more cumbersome. We figure customers want things like applying an MSI-base application patch to "just work" without any extra steps just because SVS is being used.
Selfhealing apps
In the last year i builded hundreds of packages, and i never, and i mean never builded a selfhealing package.
Why should i.
The best part of SVS is the reset function.
Build you´re package like the pro´s (hmmm) do.
And if i mean build a package, do it the right way. Build it on a 2003 machine. That gives the best results.
I only once needed a repair function, and that was for the windows mobile 6.1 SDK.
Regards
Erik
www.svs4u.nl
Understood Scott....
"This is not recommened on apps that you would like to upgrade inside the layer."
This is a reccomended solution for applications that are in MSI format and you have no need for it to upgrade. This has worked well for me as it allows me to keep tight reigns on the versions of apps that are in the company amongst other things like; actually using the reset for a repair.