Working with multi-gigabyte setups has taught me that compressing cabinets can be very time-consuming. Of course, it can also be vital — Flight Simulator X barely fit on two DVDs; without high compression, it would have required a third disc.
As I work on the WiX tooling and authoring for upcoming products, I knew I needed to support multiple compression levels: no/low compression for developer builds, “normal” MSZip compression for daily builds, and high compression for milestone builds.
By default, a Media element with no CompressionLevel attribute gets MSZip compression, which offers a nice compression-to-time ratio. A typical approach to control compression level outside the authoring is to pass in a preprocessor variable via the MSBuild project and use its value in Media/@CompressionLevel. That works but is kind of clunky.
So I decided to address the clunkiness by adding support to override the default MSZip compression level. Here are the two steps to take advantage of this feature:
- Author Media elements with a Cabinet attribute but without a CompressionLevel attribute.
- Pass -dcl:level on the Light command line, where level is none, low, medium, high, or mszip.
–or–
Declare the DefaultCompressionLevel property in your MSBuild project file, with a value of none, low, medium, high, or mszip.
There are no changes in behavior with existing authoring or build scripts. If you omit Media/@CompressionLevel and don’t use -dcl or DefaultCompressionLevel, you’ll continue to get MSZip compression.
This change will appear in the next weekly release of WiX v3.
7 Comments
Great to hear!
Can you also provide (fix the bug) the WixComPlusExtension.dll in Wix v3? I really need the dll in the .msi. I converted all projects to v3 but now I have a problem with Com installations. I know it is an open issue but i hope it will be fixed soon.
Or do you know where I can download older weekly builds? I need the build of 30 November 2007 there the WixComPlusExtension.dll is still included in the binaries.zip
Victor,
Older releases aren’t available; we get only 100MB of Web site space from SourceForge, so we have to recycle bits pretty quickly.
Getting the ComPlus and Msmq extensions building again is high on the bug list.
Bob,
Thanks for your quick response!
Hi,
I need your help on to get the setup of my wpf application using Wix 3.0
Is there a way to check if the system has .net framework 3.5 while installing?
If it is there, just install the appln without any error and if its not there,
install .net 3.5 setup exe and then continue installing the application.
Can you tell me the steps for the same.
Can you tell me that what action/condition to do this?
Waiting for your reply.
Kind Regards,
Vidhya
WiX supports the NETFRAMEWORK35 property in WixNetfxExtension to detect .NET 3.5. To install it when necessary, however, requires a chainer, which isn’t yet available in WiX.
We’re migrating our product from Inno Setup to Windows Installer, and the installer size has doubled with .msi. The solid LZMA archive supported by IS does a whole lot better than whatever Microsoft calls “high”.
But this is still a useful feature, though - I’ll use weak Microsoft compression for daily builds, and _no_ compression for milestone releases–because then our bootstrapper (which extracts the .msi and does language transforms) can use LZMA to bring the whole thing down to size.
Jeremy,
Yep, LZMA is a great algorithm; CAB definitely hasn’t kept up.
Let me know how it works using LZMA on no-compression cabinets. I’m wondering whether they’ll work well with solid compression.
3 Trackbacks/Pingbacks
[...] Add default compression level for cabinets, as discussed previously. [...]
[...] Bob Arnson recently posted some information about a new feature he contributed to the WiX toolset that I wanted to link to here. This feature allows you to pass a new switch named -dcl to the WiX linker (light.exe) to specify a default compression level for all of the cabinets in a package. This type of global setting can be useful when using WiX in an automated build system where you’d like to allow developers to create buddy builds with no compression (to speed up buddy build times), but would also like to ensure that daily builds and release builds are compressed. [...]
[...] might make some more backward-compatible tweaks to simplify common tasks, like we’ve done a few times [...]
Post a Comment