Grab our RSS feeds Follow us on Twitter Join our Facebook Group Connect with us on LinkedIn
myITforum.com, Powered by You.
you are not logged in

Articles

Newslinks

Links

Downloads

Site Services

Community Forums

Discussion Lists

Article Search

Newsletter

Web Blogs

FAQs

Live Support

myITforum TV

Take a Poll

Monthly Drawing

myITforum Network

User Group Directory

Our Partners

About Us

Register

Login

BRONZE PARTNER:

BRONZE PARTNER:



Industry News:




  Home : Articles : Software Management print | email | | Forums |   print | email | | Blogs |   print | email | | Wiki |   print | email | | FAQs |   print | email | Article Search  
The three biggest mistakes in Windows Installer repackaging


Bookmark and Share

By: Stefan Hotan
Posted On: 5/7/2004

1. Building ‘Golden Packages’

The Mistake: Using Validation tools until a repackaged application shows no error or warning message.

The Answer: Use the Validation tool only to identify real errors that will make your installation fail or run badly. In repackaging it can be impossible to fix certain warnings or even errors. Fixing warnings or errors can even make the application fail to work properly. Only fix errors and warnings that will cause your installation to fail or your product fail to start.

2. Using the advertised table group

The Mistake: Using Class, ProgId, Extenstion, Verb and TypeLib Table.

The Answer: Of course the Class and ProgId table will create Windows Installer Entry Points but they also cause problems for some applications. In general, those tables should be used by developers only. If you need the self-repair mechanism to install per-user components on demand, just use the advertised shortcuts as entry points. If you repackage an application, use the registry table instead of the advertising tables. Applications based on legacy setups are not designed for Windows Installer and they will run better if you use the registry table for registry keys.

3. Using transforms on vendor msi packages

The Mistake: Using only transform files to install a msi setup to meet your requirements.

The Answer: Two years ago this wouldn’t have been a problem, but nowadays more and more msi packages are being created by application developers. Unfortunately, they produce the same catastrophic installations in msi as on legacy setup, which means they don’t care about silent installation, repair and other great Windows Installer functions. Sometimes it takes longer to get a transform working than to repackage the application. Of course applications like Microsoft Office shouldn’t be repackaged at all because the program code itself uses the Windows Installer APIs.
Don’t spend hours trying to make a transform file work if the vendor doesn’t support silent installation or if he has built in a ton of custom actions to make your repackaging life harder. Just repackage the application if you think it will be faster than building a complex transform file that changes almost the whole msi file.

Stefan Hotan
Senior Windows Installer Consultant
www.windowsinstaller.ch

Thanks again to Agustin Musi for English editing.


  myITforum.com ©2010 | Legal | Privacy