This wrap up is mostly content free but maybe the context is interesting.
If it hasn’t been clear from Bob’s weekly highlights, we’re all about fixing bugs in the WiX toolset right now. Not much to report this week but next week should have more interesting details… and I’ll hopefully have my hair cut.
Original post by Rob Mensching
Qik is working on my phone again so I thought I’d try getting back on the video horse. I conned Bob into holding the phone for me. But, I was still nervous about starting. So, we were talking a little bit and I realized that I was starting to address a comment left on my blog a long time ago. The comment went something like, “I prefer when you write blog entries instead of embedding video content because I can digest the text better than the images.”
To loosen up a bit, I told Bob to record and I’d take a shot at answering the comment:
So to summarize, these videos aren’t really intended to deliver technical content. Instead they are attempts to provide more context about the people that are doing the technical things. There is a lot more to the people that write the letters that appear on your screen and I’m experimenting with ways of expressing that.
I’m obviously still experimenting with the new technology here so your feedback is very interesting to me.
Â
Original post by Rob Mensching
For most people this isn’t going to be a surprise and many may even ask what took so long. To be truthful the keys were granted a few weeks ago, I’m just finally getting around to blogging about it.
Over the last couple years, Bob Arnson has become a vital member of the WiX toolset going far beyond the call of duty. His first core role was taking ownership of the WiX UI providing some key functionality to the WiX community. Bob also became the regular “answerer of questions” on the wix-users mailing list taking a huge load off my shoulders. In the last year, Bob has contributed to all facets of the toolset and participates in or leads all major decision making for the WiX toolset.
Needless to say, Bob has become a vital member of the WiX community and I appreciate his efforts whole heartedly. I rely on Bob’s contributions so much that three weeks ago I promoted him to co-administrator of the WiX toolset on SourceForge
Like all good promotions, nothing really changes (well, there is a 100% increase in pay). Bob has already been doing this job for a while now and we’re really just improving our bus factor.
Seriously, though, this is recognition of Bob’s outstanding work on the WiX toolset. If you haven’t sent a happy thought to your friendly neighborhood WiX volunteer, send a happy-gram to Bob and thank him for his efforts.
Â
Original post by Rob Mensching
I just received notification that this week’s weekly build of the WiX toolset has just been released. Since SourceForge moved their servers from California to Chicago we’ve been having issues getting builds posted regularly. The mistakes were all on our side (we missed the memo
Sorry for any trouble these issues might have caused. Now back to the coding.
Original post by Rob Mensching
One of the cool contributions Visual Studio is making to the WiX toolset is the attention of a technical writer, Martin. Improving the WiX documentation is a constant request so any help someone is willing to provide is much appreciated. Of course, when there is very little information about a particular feature then technical writers have nothing to work their word-smithing magic on. Martin pointed out one such area recently: .wixlibs.
What is a .wixlib?
At its most basic level a .wixlib is simply a collection of .wixobjs. That hopefully isn’t surprising since the input to the tool that creates .wixlib files, lit.exe, is a bunch of .wixobj files. If you look into a normal .wixlib, you’ll see that it is just a <wixLibrary/> element wrapping a bunch of <section/> elements which is exactly what the <wixObject/> element does.
The difference is that a .wixobj contains only the sections from a compiled .wxs file while a .wixlib contains the sections from all of the .wixobj combined together by lit.exe. Another difference is that lit.exe can create a “binary .wixlib” which also combines all of the files referenced by the .wixobj files into the .wixlib. The “binary .wixlib” is a feature that was added in WiX v3 and is not available in WiX v2.
Ultimately, .wixobj and .wixlib files are passed to the linker, light.exe, to be processed into an .MSI or .MSM file.
Why would you use a .wixlib?
Since .wixobj and .wixlib files can be used interchangeably, you might wonder why bother with .wixlibs. There are a few reasons to consider.
1. Fewer files to link. If you product is very large and has lots and lots of .wixobj files then the linker may spend more time reading the many small .wixobj files than it would reading fewer but larger .wixlib files. If your build system allowed you to build .wixlibs in parallel then you may get better overall build throughput.
2. Fewer files to share. If you need to share setup logic with people who are using the WiX toolset, you can combine several of your .wixobj files into a .wixlib file or two. One or two files are certainly easier to consume than a directory full of .wixobj files.
3. Abstracts the source file organization. Similar to #2 but a little different. Since you get one .wixobj per .wxs file any changes to the organization of your source code mean that downstream consumers must also change, even if it is just to add another .wixobj file name to the light.exe command-line. If you share .wixlibs then you abstract away the number of .wixobj flies from the consumers of the .wixlib, simplifying their life. And who doesn’t want to make their customer’s lives better?
4. Binary .wixlibs are a better Merge Module. If you are sharing setup logic with people who are using the WiX toolset then binary .wixlibs are far superior to Merge Modules. The linker can introspect into binary .wixlibs better than Merge Modules providing better linking and error reporting. The linker can also access the embedded files more efficiently than the files in Merge Modules. Finally, .wixlibs provide infinitely better information than Merge Modules for patching.
Why wouldn’t you use a .wixlib?
If your build isn’t huge and highly parallelized and you don’t share any setup logic with other WiX users then .wixlibs are probably just overhead. Also, if you need to share your setup authoring with customers who are not using the WiX toolset then you’ll need to use Merge Modules not .wixlib files.
How about a bit of history?
Sure, I love to talk about the history of features. As you might guess, the history of .wixlibs starts with Merge Modules. I wrote the Merge Module spec back in 1998 when I was an intern on the Windows Installer team. The goal was to create a mechanism for developers to share setup logic and the respective files.
When I later joined Microsoft full time in 1999 and started working on WiX v1 I had the idea that Merge Modules could be used as the building blocks to create large complicated setups. To make a long story short, that design was flawed because the Module Id appended to all of the primary keys made things difficult to integrate and Merge Modules did not provide quite the right granularity for all pieces of a product.
So, in WiX v2 I introduced the concept of symbols/references, sections and library files. Unfortunately, in WiX v2 there were no binary .wixlibs so you had to distribute any referenced files along with the .wixlib. That was a pain. Derek fixed that issue in WiX v3.
One of the first big changes to WiX v3 was to add the ability for lit.exe to create “binary .wixlib” files which contained the referenced files in a cabinet file prepended to the .wixlib’s XML blob. This gave us the best features of both of .wixlib files and Merge Modules, as long as you are using the WiX v3 toolset everywhere.
These days I always recommend that if you are sharing setup logic and files with people also using WiX v3, skip Merge Modules and just use binary .wixlibs.
Â
Original post by Rob Mensching