5 replies to this topic

[dxue]

Our application needs to deploy more than 300 files to the target system. If I have to stick on to the component creatinon rules that are specified in Windows Installer SDK documentation, that would be a lot of manul work. It would also mean the difficulities in maintaining the list of components. Are there any best practices specificlly for deploying large scale applications? Your insights are greatly appreciated.

[Glytzhkof]

The golden rule I normally use is: Any file that may at some point require to be delivered separately, should be installed with its own component from the start. Everything else I try to merge into larger components. Frequently I use flag files for large components with many files. That is a dummy file with version information in it set to be the keypath of the component. That way I can increment the version of that file to ensure all files in the component gets update. Other than that you should always use separate components for EXE, DLL, OCX, CHM, SYS etc... Stay away from Installshield's "dynamically linked components", and remember that removing or adding files to existing components is a bad idea if you want to use patches or minor upgrades. Was that an answer to your question?

[dxue]

Thanks very much for the advices. They are what I want. Is that true that component rules only matter to patching and minor upgrade?

[Zweitze]

Another area for component rules is multiple installs installing the same files/components. Eg. if you have internal libraries for your products, and multiple products may be installed on one computer, be careful. Consider MSMs for this situation.

[Glytzhkof]

Zweite is very right about this. If you install a system resource or a shared component with your own hard coded GUID (which you should never do) you are telling the system: "reference count this file / resource based on this GUID". Since no-one else will use your unique GUID your application will remove the resource on uninstall (unless you set it to be a permanent component).

Extreme Sample:

GUID: {00000000-0000-0000-0000-000000000001}
File: C:\Boot.ini

This file is not yours, so:
1) You shouldn't install it in the first place
2) If you install it you should never remove it

If you did the above anyway your MSI would most likely cause the system to not boot properly since it would remove boot.ini on uninstall (the OS would probably prevent this from happening, but this is just an extreme sample). In short: component rules are NOT just important for minor upgrades and patches.

Moral: do your best to keep the reference counting of your own files clean, and for God's sake make sure you keep it clean for any shared components you are hacking. The proper way to work with shared components is to use merge modules.

If you want to update a shared resource but not register the change with windows installer, a hack you can use is to use a component with a blank component GUID. Not recommended though.

Edited by Glytzhkof, 24 June 2005 - 16:47.

[dxue]

Thanks Glytzhkof and Zweitze for sharing your insights. I appreciate them. And keep on doing this if anything else coming up to your mind