To Cab or Not to Cab?
Filed under:
Wise Package Studio
Best Practices
Submitted by WiseUser on Tue, 2008-05-13 09:32.
A cabinet is a single file, usually with a .cab extension, that stores compressed files in a file library. The cabinet format is an efficient way to package multiple files because compression is performed across file boundaries, which significantly improves the compression ratio.
Read on to learn more about cabinets and why they're a good thing.
Best practice is to compile the package to get an external .cab:
- It is always better to get an external .cab file for distribution.
- It's easy to share or distribute .cab files since they are seperate from the MSI database.
- You can extract files from a .cab as easily as you can extract files from a .zip archive.
- You can always get the installation files with the help of the .cab file even if the .msi is corrupted.
- Internal .cab compiling makes the .msi bigger in size.
Comments \ suggestions are most welcome ...
(42 votes)
- Login or register to post comments
- 434 reads
- Printer-friendly version
Uncompressed external files
Using Cabinets is always a question regarding network load and possibility of corruption during "transfer" over the network before extraction during install from a network location.
However to patch an MSI external files are required.
Internal cabinet(s) makes it more or less impossible for the user to forgett to copy the cabinet(s) while copying the MSI to another location.
So it's a question of taste and requirements
Very important for large applications
One very important reason to use external cabs is when you have very large installations that will trigger a self healing event for missing HKCU or C:\Documents and Settings (C:\Users in Vista) files or registry keys.
When that event is triggered, Windows Installer will pull the entire original MSI down from the source location to perform that self heal. If all you are doing is adding some registry keys this would be a tremedous amount of data transfer for a small benefit.
Be careful when defining your feature layout to make sure that you pull only required information down for a self repair event.
Control via Features
I notice you mention the feature layout but:-
If you have a BIG MSI file and have HKCU that will be repaired, you should control the repair behavior via features, like the HKCU feature at the top of the Feature list (Parent). If the HKCU feature only has Registry entries then it will repair from the local cached copy (Windows\Installer) if nothing else is broken.
re: Control via Features
Not entirely true.
The self-check for broken components will be done from the feature the entrypoint resides in and every parent feature of that feature. If a broken component is found (missing or corrupted keypath) the entire feature tree will be checked for broken components and repaired if needed.
John (McFadyen) as written a nice article regarding Windows Installer Self healing.