Highlights of WiX v3.0.4311.0

WiX v3.0.4311.0 was released on Friday, 11-July-08. You can download it from http://wix.sourceforge.net/releases/3.0.4311.0/.

New features

  • Neil Enns, late of the MSBuild team and now working on secret stuff, contributed a new section of how-to topics for WiX.chm. (This was actually new in v3.0.4220, but I didn’t catch it. Mea culpa!)
  • Neil also added support for multiple .wxl (loc-string collection) files in .wixproj projects.
  • The SecureObj custom actions, triggered by the use of the PermissionEx element in WixUtilExtension, now support 64-bit systems, including both x64 and IA64.
  • Jason added support for MSI 4.5 multi-package transactions to DTF.
  • I added new file-i/o functions (FileReadPartial and FileWrite) and error reporting for XML parsing errors to the dutil library.
  • Aaron added new documentation in addition to fixing WixUI bugs.
  • Votive now has fancy new high-res/high-color icons on Windows Vista.

Bug fixes

6 thoughts on “Highlights of WiX v3.0.4311.0”

  1. Thanks for providing updates on what’s new in WiX. However, would it be much more work to also add the title of the bugs fixed in addition to the link? Now I have to click each and wait for SF to see if it is an interesting bug or not.

  2. There is a more fundamental problem: lack of release automation in interacting with SourceForge.

    It manifests itself in many ways such as files routinely missing from drops, relying on weekly release mechanism instead of v3 release because it’s easier that way, difficulty in being able to communicate what’s in a release and so on.

    Even Rob is publically expressing frustration with SVN.

    http://twitter.com/robmen/statuses/841808073

  3. Chris,

    You appear to be confusing the build system with the hosting site.

    1. On the rare occasion a file is “missing,” it’s because a developer forgot to update the publish project to include a new file.
    2. Even if it were easier to publish release on SF, we’d continue to publish weekly builds and push known-good ones as SF releases.
    3. The “what’s in a release” is covered by history.txt, which is automatically tagged during the build.

  4. I didn’t mention the word `build`, I mentioned `release` which is a process involving the build and hosting systems.

    Something seems wrong that it’s possible to drop an MSI that includes a file that the sources doesn’t include. It tells me that two different paths are being taken.

    I also know that Rob has specifically posted in the past that SF being a pain is the reason for relying on weekly builds and very, very rarely pushing an SF release.

    Also I don’t believe in relying on a txt file to keep track of changes. I use systems like TFS that allow me link source control changesets to work items. Checkin policies help enforce the business rules to make sure valid data is avaialable.

    When doing a build, I can fully automate a report to include the descriptions of work items included since a previous build and to be able to get, zip and drop all files that corrospond to the changeset used to do the build.

    I know your an agile guy and know all this, it’s probably just a matter of finding the time to do it and something better then SVN to try to integrate with.

Comments are closed.