Luke Melia

In order to get Wix to generate good MSIs, you can have no more than one DLL/EXE per component. In addition, each component needs it’s own GUID. My team wanted a way to automate the definition of these components for our .NET apps as part of our automated build process. We tried using tallow/mallow, but that didn’t really work out too well for us.

Here’s the solution we came up, in a nutshell: a custom nant task runs against a build directory and catalogs all files in an XML file. Special logic applies for DLLs and EXEs, which get inspected and have relevant metadata added to thir elements in the XML. Once we have this XML, we apply an XSLT which transforms it into a Wix-friendly fragment file. We made one XSLT for executables, and another one for web services. We activate this XSLT as part of our nant script, and then included it in the call to Wix.

I’m including code listings for the relevant files here. It’s available for use under a BSD license, which I’ll include at the bottom.

The nant custom task: “BuildOutputToXmlTask.cs”

The XSLT for transforming a Windows executable project: “OutputToComponents.xslt”:

The XSLT for transforming a web service project:

A snippet of a nant build file showing the use of this code:

Copyright and open source license:

Simon Willison has a post up called Maintainability, a.k.a. the CSS elephant.

What’s needed is a well understood set of techniques for writing maintainable stylesheets. I’m interested in collecting advice on this, especially from people who have tackled this problem in a situation where more than one person has to work on the same CSS code. I’m particularly interested in ideas on how to best split up a large set of rules over multiple stylesheets. If you have any tips, please post a comment, write it up on your own site, e-mail me or add it to the wiki page.

I can understand the concerns, but my experience is that the modular CSS approach is a sufficient solution. Limit the universe of css styles affecting a particular page, and the complexity tends to stay managable (assuming your page structure is clean and you’re reasonably well-versed in selectors). David Hyatt’s notes on Good CSS at Mozilla.org are also a useful, particularly due to Hyatt’s insight into performance of CSS selectors.

For several months now, I’ve felt it would be valuable to post blog entries about problems, solutions, tools and ideas in software development. After all, I spent a good chunk of every workday thinking about this stuff, and a fair bit of weekend, evening and dream time, too. I resisted posting to my blog on this site, because it’s read by friends and family who in significant majorities, would be lost, bored, and searching for pictures of my daughter between code snippets. Likewise, software professionals who might find my coding thoughts useful, probably don’t care too much about my last beach volleyball tournament.

So, here we are. The link to the blog’s home is lukemelia.com/devblog/. The RSS feed for the main site will include posts to both blogs for now. The RSS feed for the dev blog is here. There are still some navigation issues to work out on this site. In due time…

I plan on covering a wide swath. My day job is in C# primarily. I manage a small team for a cable television network and we use an agile approach. My freelance projects are mostly for web sites and I do LAMP stuff mainly. Lately, I’ve been teaching myself Objective-C and Cocoa, and I’m hankering to get some experience with Python and Ruby. In former incarnations, I did a ton of perl and Java.

And away we go…