MSI Advertising Tables (Class, ProgID, Extension, etc)
Hi,
We currently use Wise 5.6 and have repackaged thousands of applications over a 3 year period into MSI format for use on Windows XP. As part of this we have always left the option available in SetupCapture to rescan advertising registry entries into their appropriate tables, e.g. Class, ProgID, Extension, etc with no apparant issues.
We have recently started working with our colleagues in I.T. departmens within our other european branches who share a different view and adopt the approach of not using the advertising tables at all and leaving registry as is when recapturing, however they are just getting their feet off the ground so are new to MSI technology.
We are trying to merge our packaging processes and this is one of the points we are disagreeing on so would appreciate some comments and advice. Based upon our existing points:
Reasons given to rescan registry into advertising tables.
Reasons given to retain registry information as is
We currently use Wise 5.6 and have repackaged thousands of applications over a 3 year period into MSI format for use on Windows XP. As part of this we have always left the option available in SetupCapture to rescan advertising registry entries into their appropriate tables, e.g. Class, ProgID, Extension, etc with no apparant issues.
We have recently started working with our colleagues in I.T. departmens within our other european branches who share a different view and adopt the approach of not using the advertising tables at all and leaving registry as is when recapturing, however they are just getting their feet off the ground so are new to MSI technology.
We are trying to merge our packaging processes and this is one of the points we are disagreeing on so would appreciate some comments and advice. Based upon our existing points:
Reasons given to rescan registry into advertising tables.
- It follows the rules set out by the Microsoft SDK that the advertising tables are the optimum place to for COM and Shell registry entries as it is a more logical structure and can minimise erroneous registration of COM server information.
- One of the big selling points of Windows Installer is the ability to provide resilient applications through the use of self healing. One of the key things that needs to be in place for this to work is the advertising tables as otherwise you are only relying on the shortcut.
- My point regarding the above is if you aren't going to use one of the big selling points of Windows Installer (resilience) then what's the benefit of repackaging into MSI format over the legacy setup you are recapturing?
- In reference to the above point more and more applications are being integrating together and as such launched from each other using file associations, CLSID calls, etc, than directly from the shortcut, which without additional entry points is a single point of failure.
- The registry information can become static when it is only contained within the registry. Allowing registrations to occur via the appropriate tables can ensure the registrations are more consistent and accurate.
- An increasing amount of manufacturers MSI's including Microsoft's and third party ones have been supplied with advertising tables populated. Merge modules from MS and other manufacturers also use the advertising tables.
Reasons given to retain registry information as is
- Random self heals can occur when you are least expecting them to occur which can be confusing to the users. (My own comments regarding this would be that if a "random" self heal occurs then either the application has been corrupted in which case its a good thing as the alternative would have been the application wouldn't have worked, or the MSI has been packaged incorrectly.)
- The machine can be slow as Windows Installer has to constantly monitor each and every entry point on the machine against the Windows installer database. (In tests we've not encountered any speed differences between using entry points and not using them.)
- Legacy setup.exe applications are not designed to use Windows Installer technology and as such shouldn't have registry entry points added. (While I can see the angle behind this a few years ago when Windows 9x systems were more popular, even legacy setups have advanced somewhat in their support for the windows operating system so generally handle registrations better which is reflected when repackaging. The repackaging tools, e.g. Wise, also will only convert those registry entries into advertising tables that are supported by the tables themselves so the worry about the legacy setups not supporting Windows Installer is irrelevant.)
- Terminal services doesn't like entry points so shouldn't be used. (While I agree that self healing shouldn't be done on TS to self heal user components as it contains it's own HKCU reg key healing, I can't see what the issue is with allowing the MSI to self heal for resilience if broken.)
There's been a number of discussions on the internet about this with some good points being raised by Michael Sanford on the pros of usings COM Advertising, but it's still not a resolved issue.
http://msmvps.com/blogs/michael/archive/2004/12/22/26726.aspx
http://msmvps.com/blogs/michael/archive/2005/01/10/31359.aspx
http://msmvps.com/blogs/michael/archive/2004/12/23/27169.aspx
Cheers
Craig
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
AngelD
17 years ago
Is the discussion only about the "Default to rescan advertising for new components" option or advertising COM components and file extensions in general?
Posted by:
AngelD
17 years ago
The decision is up to each other but for the resilience (self-heal) support for other then Advertised shortcut the advertise related tables should be used.
I always configure Wise to "Convert registry entries into advertising info".
There have only been once i've used "Retain registry information as is" which was for Winzip due to it's issues when selecting create new zip file.
Except for that I only use "Retain registry information as is" when troubleshooting and installation or capture settings.
So if you want the application to repair for other actions except when launching the (advertised) shortcut I would recommend to "Convert registry..."
If you decide to use "Retain registry information as is" and you have more then one feature it will not be guarantee that the application will trigger a repair depending on your location of entry points in the feature structure.
If I recall a regular user do not have permission to self-heal applications on Terminal Server.
I always configure Wise to "Convert registry entries into advertising info".
There have only been once i've used "Retain registry information as is" which was for Winzip due to it's issues when selecting create new zip file.
Except for that I only use "Retain registry information as is" when troubleshooting and installation or capture settings.
So if you want the application to repair for other actions except when launching the (advertised) shortcut I would recommend to "Convert registry..."
If you decide to use "Retain registry information as is" and you have more then one feature it will not be guarantee that the application will trigger a repair depending on your location of entry points in the feature structure.
If I recall a regular user do not have permission to self-heal applications on Terminal Server.
Posted by:
AngelD
17 years ago
With regards to the repairing on TS I thought that as long as the initial installation was done under an admin context that the install then becomes a managed application so any subsequent maintenance activities (e.g. self heal) are done with elevated privileges?
My experience regarding TS is that regular users do not have permission to self-heal even if the installation was done with elevated privileges.
Posted by:
AngelD
17 years ago
Did they say why they did not recommend using the advertising tables?
I can understand why in a TS environment if any regular user do not have permission to self-heal an application but not on a regular client.
I can understand why in a TS environment if any regular user do not have permission to self-heal an application but not on a regular client.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
