RobMensching.com /Blog
when setup isn't just xcopy

64-bit MSI packages require Windows Installer 2.0.

File this tidbit under documented but cryptic and missing an error message. I was recently creating 32-bit and 64-bit MSIs using the WiX toolset. The very helpful -arch command line switch to candle made it easy to build for both architectures with the same codebase. Maybe a little too easy.

The 32-bit MSI worked great. However, trying to do anything with the 64-bit package (including validation) always gave the error message:

This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package.

That stumped me for a while. For some reason, I kept coming back to the Package element in my .wxs file. Something didn't seem quite right. It looked like this:

<Package InstallScope="perMachine" Compressed="yes" />

See anything wrong? I'm building a per-machine install with all the files compressed so that's all good. The -arch command line switch is going to handle setting the Package/@Platform attribute for me correctly so I don't need that attribute.

I ended up reading the documentation again and again before I came across this little gem in the Package element documentation that I had totally forgotten.

InstallerVersion - The minimum version of the Windows Installer required to install this package. Take the major version of the required Windows Installer and multiply by a 100 then add the minor version of the Windows Installer. For example, "200" would represent Windows Installer 2.0 and "405" would represent Windows Installer 4.5. For 64-bit Windows Installer packages, this property must be set to 200 or greater.

That last bit is my emphasis. Of course! 64-bit packages were not supported until Windows Installer v2.0 so you need to mark the package as such. The fix? Easy.

<Package InstallScope="perMachine" Compressed="yes" InstallerVersion="200" />

I was happy to have a fix in hand but disappointed the WiX toolset didn't catch this for me. I opened a bug to track the issue and will fix it sometime in WiX v3.5.

In the meantime, remember when creating a 64-bit package, be sure to mark your package to require Windows Installer 2.0 or better.

 

Burn packages, payloads and containers.

In my previous blog post where I introduced some of the features of Burn the question whether Burn would work as a single self extracting executable was asked a few times. The answer is, "Of course!" but there is actually more to it than that.

I debated listing "containers" as a feature in the previous blog post. Looking at the comments, it's pretty clear I should have. The "container" concept is still under some design tweaks but it is shaping up to be quite a powerful concept (and it addresses the question many asked).

So let me walk you through the list of primitives that Burn will process and how they stack together.

Packages

A package is a unit of change (install, repair, patch, uninstall) for the bootstrapper. Packages are members of a chain that the bootstrapper manages. There must be at least one package or the bootstrapper has no work to do. Each package has an implicit payload that is the entry point for the change (for example, an .MSI file or .EXE file). Additional payloads and containers may be referenced by a package.

Payloads

A payload is a file that contains data required by a package. The bootstrapper treats payloads as opaque blobs therefore there are no bootstrap related requirements for payloads. Payloads may be found as loose files outside the bootstrapper or combined with zero or more payloads in a container.

Containers

Containers are a way of combining one or more payloads into a single file. Usually containers are used compress the contained payloads to make the total distribution size smaller. Sometimes containers are used simply to minimize the number of files that must be distributed with the bootstrapper. The bootstrapper controls the format of the containers and is responsible for extracting payloads out of the containers during the cache phase.

The ideal container file format will optionally compress various file types well, support digital signatures and scale to very large file sizes while containing many payloads.

Attached container

An attached container is found at a specified offset in the bootstrapper itself. The container is called attached instead of embedded because it is found at the end of the bootstrapper, after all of the executable code and resources. There can be only one attached container. When the bootstrapper is signed the attached container is included in that signature.

It is expected many small products (< 300 MB when compressed) will distribute a single file bootstrapper where all of the product’s payloads are compressed into the attached container.

Detached containers

A detached container exists as a file outside the bootstrapper. The bootstrapper manifest can reference any number of detached containers. Detached containers are highly recommended when the combined size of the bootstrapper plus attached container would exceed 300 MB. Larger executable files experience poor start up performance on Windows leading to a less than ideal user experience.

Detached containers can also be used to optimize download scenarios because the bootstrapper will only request the containers referenced by packages being cached. For example, a very small bootstrapper would provide the optimal download + start up user experience then provide a custom user interface while the minimal number of detached containers are downloaded from the Internet.

Also note that if there are very few payloads and they are already compressed, it may be optimal to forego the use of detached containers completely. Containers do add overhead because they must first be downloaded before the payloads are extracted which requires more disk space and file I/O than simply caching the payloads directly.

Summary

The goal in Burn is to provide enough flexibility to meet everyone's needs. The WiX toolset will ship the tools necessary to create and bundle these primitives together. Ultimately, the decision how to organize your content into packages, payloads and containers is up to you.

I know there are many other questions about Burn. I'll get to them as soon.

 

Open Source at Microsoft in 2009.

It was almost ten years ago that I started a little project inside the firewalls of Microsoft called the WiX toolset. I called it a "Community Source" project because inside Microsoft the words "Open Source" only had negative connotations. I never would have guessed that 5 years later I would help reshape Microsoft's approach to Open Source by releasing my little project. Now 5 more years later, Microsoft takes another big step and contributes to the most famous Open Source project of all, Linux.

Mary Jo Foley (who originally broke the news about the WiX toolset) references flying pigs. Todd Bishop (whose write up about WiX printed in the Seattle PI I still have) tosses in a little more historic context. However as I read those blog posts then others then comments all around, I felt like a few key questions were never asked and thus never answered. I thought they were interesting and captured some of my opinions on this topic.

Please note that I'm not on Sam Ramji's team and cannot speak to Microsoft's Open Source strategy. These are just my views of how Microsoft has changed over the years.

Q: Everyone is making this out to be a big deal. Jim Zemlin said this isn't that big of deal, "they're not saving the whales here." Why is this a big deal?

A: Code wise, maybe this isn't that big of a deal. Microsoft is just adding a few drivers to Linux so it will run better on Hyper-V. Anybody could have done that. It's just code right?

Sure, but what is different here is that Microsoft is meeting the Linux community on the community's terms. Linux is released under the GPLv2. Okay, Microsoft licenses these drivers under the GPLv2. Linux has established leaders for the major sub-systems. Okay, Microsoft works with the driver people to understand their requirements. Linux has coding standard that everyone must follow. Okay, Microsoft works on the code to meet those standards.

That's why this is a big deal. Microsoft is participating in the Linux community in a way its never done. Sure, other companies have done this already but I believe this demonstrates how Microsoft continues to learn how to approach Open Source communities and collaborate appropriately. Less than 10 years ago, the interaction could only be summed up as fist shaking and name calling. Now it's about participation for cooperation, competition and co-opetition.

Q: But isn't Microsoft contributing these drivers because they help Hyper-V?

A: In the narrowest view of the circumstances, yes. But if you look at this from a business perspective then I expect that you'll find this is more about making customers happy. If no customers wanted to run Linux on Windows then I'm pretty sure that Microsoft would not have done this work.

What I'm excited about is the fact that Microsoft finally found a way to work with the Linux community to meet a customer request. Instead of saying, "That's Linux's problem, have them sort it out." Microsoft joined the Linux community to solve the problem. Can you see the shift in thinking that occurred here?

Q: But don't you think Microsoft should have done more sooner?

A: Probably. But educating an organization as large as Microsoft about something as subtle as Open Source takes time. I do my small part by working to make my "relatively insignificant geekware" project successful. Announcements like today's recognize the larger efforts made by others.

There's certainly more work to do but in 5 years I think Microsoft has come a long way. I only hope the progress continues (and maybe a little bit faster). <smile/>

 

Sounders FC practice in our yard.

If you follow me on Twitter (@robmen), you know I've become a huge Seattle Sounders FC fan. I haven't played soccer since I was a kid but after K invited Jenny and I to a match early this season we became hooked. Now we're season ticket holders (jumped in when they opened more seats mid-season) and follow away games regularly.

Today (er, technically, yesterday) the Sounders came to practice on "the yard" at Microsoft.  Peter, K and I had unfettered viewing of the whole thing.

Here are some personal highlights:

• Watching something like 16 players split in two teams pass the ball around in such a tiny space before warming up.
• Watching Sigi stalk around calmly watching and directing. After being congratulated by the President.
• Watching Freddy Montero warm up with the ball. Amazingly effortless footwork.
• Hearing the voices and, more interestingly, the accents of the players. They are essentially silent from my perch the stands.
• Hearing Keller yell out short snippets of Spanish to direct Freddy. English for everyone else.
• Watching Freddie Ljungberg move the ball down the field. He really is brilliant at moving and placing the ball.
• Watching Keller get scored on then holler, "Awwww, shhhhhh--oot." He kept it family friendly in the last syllable. Heh.
• Having Nate Jaqua sign my Sounders FC scarf! I like the way Jaqua plays.

Anyway, it was a fantastic way to spend a couple hours this morning.