Today's entry is Windows Installer XML (WiX for short), an open source project (the first?) from Microsoft that is used internally by Microsoft development teams for building installers for many of their products.

I first used it more than a year ago when I was at Merrill Lynch.  I had to build an installer for a Windows Serivce and I wanted the service to auto-start after installation.  I was totally baffled by how to do this in the VS installer projects (is it even possible?) and somehow ended up stumbling across WiX.  It worked great It was a little rough going because there was so little documentation and Net knowledge regarding usage.

Since then, I haven't really had a reason to look beyond the built in VS installer projects, but I'm working on another complex installer scenario now and decided to check in on WiX again.  To my surprise, there still doesn't seem to exist a UI to design WiX installation packages (at least none that I came across via googling).

However, I did find a very well done tutorial.

Of course, Rob Mensching's blog is full of news and developments on WiX.

Rob mentions in his first post on the subject of WiX that:

Internally, teams such as Office, SQL Server, BizTalk, Virtual PC, Instant Messenger, several msn.com properties, and many others use WiX to build their MSI and MSM files today.  When someone encounters a bug, the community tracks the issue down and fixes it.  Now, via SourceForge.net, you have an opportunity to be a part of the community as well.

I guess it's also good to note that WiX just celebrated it's 2-year OSS status recently.

I don't understand the fascination with using Word documents for internal development specs.

For one thing, a Word document is very inefficient when it comes to conveying matters of code and design.  No syntax highlighting.  It constantly warns me that I'm misspelling my words.  It wants to adjust my indentation and paragraphs for me when I put formatted code into a document.

Even more annoying is the fact that a Word document is essentially a snapshot of what was designed, at some point in time.  Past tense.  Unfortunately, designs change and details change as developers start to dig into the software at all levels; no one person can forsee all of the challenges in designing any medium-large software product; no one person can predict all of the different, possibly better implementations and architecture.  New changes mean I get a new document in my inbox.

Using Word documents, it becomes incredibly tedious to now maintain this constant state of change.  Everyone on the team has a copy.  Yet, in order to maintain any sense of order, only one person can be the source of all of the change.  Useless.  Inefficient.  Terrible.

There's a reason why typewriters were replaced by word processors.

Enter Trac.  It does everything right that Word does wrong for documenting software specifications.  The Wiki system links text to existing tickets, source code files, and other documents without effort.  It's infinitely malleable and entirely flexible; in a sense, it's "live".  It highlights code and allows full flexibility in formatting the code.  It offers a view into your source repository.  It has a system for creating milestones and linking tickets to those milestones.  You work on documenting your part in your Wiki page, I'll document mine in my Wiki page.  All the ideas, concepts, and thoughts now sit in a central repository that is constantly evolving as the project evolves.

In short, Trac is damn near the perfect software project management application and its usefulness spans the entire lifecycle of the project, from initial design to maintenance to continuing development.

Unfortunately, I'm the only one on my team using it I don't get it.  What's the fascination with Word when an infinitely better solution is available?  I set it up and demonstrated it with the hopes that these tech-heads here would dig it and see the awesome potential it has for transforming how the development process proceeds.  And yet, here I sit, baffled by why such a tool is laid to the by-ways for Word.

I guess I'm still not there yet...

A certain sense of glee overcame me just now as I was checking the activity logs.

Perhaps one of the most exciting (yeah, I realize I'm exposing myself as a total geek by saying that) things about having a blog (or any website in general) is checking out the activity logs and seeing people coming in and out of your website (hopefully finding something useful).

The idea with my Workshop series is to provide bits of knowledge that I've gained through the various projects that I've worked on in the past in simple, easy to follow and easy to digest chunks (with lots of pictures and code samples to boot). 

Imagine my surprise (oh, Joy!) when I tracked a link to my page from Google groups!  It's one thing to have searches hit your pages...it's an entirely different feeling when someone actually references your site.

Happy is me.

Yes, I'm a dork.  And probably a noob, too

Oh yeah, we're kicking it up with the DevTool entries.

That's typically what happens as I ramp up on a project; I'll end up coming across a whole slew of awesome tools that I end up aggregating in my C:\Program Files directory (my application menu is about to go past the second page...I had to uninstall a lot of stuff previously to get it back down to two pages).

Today's entries are tools to help you think "contract first".  I hadn't really thought of XsdObjectGen.exe as a tool that helped you work in a contract first fashion, but Peter Bromberg seems to think so and so does David Truxall.

Unfortunately, XsdObjectGen.exe, as great as it was, is ill suited for .Net 2.0 and the introduction of generic types and lists.  I briefly contemplated using it for my .Net 2.0 project that I'm on now, but couldn't bring myself to it; there must be a better way, right?  Well, up until now, the only other .Net solution that I had come across was Matias Wozloski's GAT implementation (with slight modification?) of Daniel Cazzulino's (kzu) version of XsdObjectGen.  Having looked at that and the new xsd.exe that ships with VS2005, I have to say that I'm sorely disappointed in both since they rely on the XmlSchemaImporter and XmlCodeExporter classes to do their dirty work.  The resultant markup is not nearly as nice as the output from XsdObjectGen.exe.  As I've mentioned in the past (see the end of my workshop on XsdObjectGen.exe), while kzu's implementation is obviously much more flexibile since you can create new extensions and what not, it is ultimately somewhat clunky and not as easy to work with.

I briefly contemplated extracting the source from XsdObjectGen.exe and rewriting the codebase (it uses sort of an "intelligent templating" approach) to utilize some of the .Net 2.0 code features and generate better code, but after digging through it with Reflector, I realized I didn't have enough time (and I probably didn't have the rights) to extract and rewrite the codebase.

Enter dingo and thinktecture's WSCF.  While dingo is still strictly a .Net 1.1 tool, the project leader has a recent news item that claims forward development will continue this summer after some more work on a rules engine (anyone know of .Net APIs for working with RuleML?).  WSCF, on the other hand, looks like it's good to go with respect to .Net 2.0.

So have a look at WSCF.  I'll be downloading and evaluating it today and keep this updated with my take on it.

Update: See comments.

I thoroughly enjoyed this post

I installed an updated version of the NUnit VS add-in (aka: TestDriven.Net) today and discovered this little tool called NCoverExplorer.  Curious, I started to dig into it and that lead me to NCover.  NCoverExplorer is a GUI interface to NCover output files. 

What is NCover?  It generates code coverage information when it runs your NUnit tests so that you can see how much of your code base your tests are really touching (I perfer the output from Cenqua's Clover.Net, but I guess that's just a matter of using a better XSL transform?).

Both are great tools and should work their way into your development cycle!

It helps to have a simple batch file to run it:

"C:\Program Files\NCover\NCover.Console" "C:\Program Files\NUnit-Net-2.0 2.2.7\bin\nunit-console.exe" "..\bin\debug\SomeProject.Tests.dll"

PAUSE

In an automated environment, you'll want to take out the PAUSE.  It's only there so that if you're running it manually, you can watch the result of the run.

Man, this thing is dense.

I was able to get a very snazzy sample up and running with Castle.Windsor in under an hour, but it'll take quite a bit of time to get the same demo working with ObjectBuilder.  Admittedly, the PAG team states that it wasn't designed for prime time (yet), but what I would be interested in is seeing Microsoft integrate some open source projects into their own OSS projects.  Why reinvent the wheel? 

From my brief review of ObjectBuilder, it seems like it requires way too much work to use at this point.  It uses a mixture of configuration and compile time attributes to make the magic happen.  Why not have the option of doing it all in the configuration file?  It seems to require a lot of custom code to utilize ObjectBuilder whereas the Windsor container requires almost no custom code for wiring; it can be done in one line of code.

On a tangent, I found out that contrary to lack of activity on NDoc, a 2.0 version is in the works and has been mostly underground due to the fact that it's, from what I gather, a complete rewrite.  I tracked down a post by Kevin Downs, the project leader for NDoc over at Fabrice Marguerie's blog dated 2/23/2006:

Originally I had planned to do a simple upgrade of NDoc 1.3, but this proved almost impossible. NDoc2 is, to all intents and purposes, a complete rewrite (a huge undertaking) and has taken far longer than I originally anticipated due to illness. I was forced to 'go dark' on this development because I was getting some fairly offensive emails *demanding* a new release, and I could not give a firm time-line due to the above mentioned illness.

So if you're interested in being a tester, track down Kevin and get on the mailing list.

Every developer/graphic artist hybrid like me eventually comes across the need for some spiffy icons to go with our badass applications.

Good icons are hard to find.

Good free icons are harder still.

So it's a rare moment when I come across good, free icons.  So I must share

http://www.famfamfam.com/lab/icons/

Excellent icons.  Enjoy.

So I'm back from Utah.  Quite a trip.  I left New Jersey Monday morning at ~7:00AM EST and touched down in Utah ~11:00AM MT.  It only dawned on me when I got into the office there that it was quite a morning commute

Some of the highlights and commentary from the week that was (in random bulleted list format):

• Brad, our CEO, cooked for all of us one night at his house.  Made some very delish fresh baked bread, pasta, and jumbo tiger shrimp from Costco (I'm gonna have to go pick some up one of these days too).  I remarked to my wife that the square footage of his kitchen is larger than the footprint of our townhouse.
• I have a distaste for American cars.  Numb steering feel has to be my number one complaint.  The Cobalt just feels terrrrible with regards to steering feedback.
• Wow.  I was able to convince everyone on the team to use Subversion and Trac.  Amazing.  So I spent most of Thursday night setting up Subversion over Apache and also setting up Trac as well.  Took me roughly 6 hours ...and I'm still not 100% done.  But I'm excited.  I've just had terrible experiences with VSS.  It had gotten to the point where I was doing a daily .zip backup of my local files to an external HD since I didn't trust the VSS repository.  It's also great that it runs over HTTPS; much easier to bring new team members on board and we don't have to worry about licensing.
• We also decided to go with .Net 2.0 and VS2005 for all new development.  Woohoo!
• Brad is quite excited about Trac.  I'm slightly concerned that he's going to go crazy making tickets.

Now some not so random stuff.

It took me exactly 12 hours to get from Salt Lake back to New Jersey.  My return flight was supposed to stop over in Cincy, but because of thunder storms, we were diverted to Chicago.  Very scary stuff.  The pilot was trying to squeeze into a small window in the storms to see if we could get in there, but seconds later, came back on and let us know that we were running out of fuel.  We had to touch down in Chicago to pick up more fuel.  All was well, but I missed my connecting flight out of Cincy once I got into there.  So had to settle for a later flight

I don't think I've ever really been afraid of flying since I've been flying around since I was a toddler.  But for a brief moment, a deep sense of grief and fear overcame me as we were in the sky, being battered by the turbulence and hearing the pilot tell us that we were running out of fuel.

Aside from the return flight, it was a good trip.  I think we really had a better sense of team this time around and it'll be good to have Brad around now since it gives a better sense of purpose and clearer direction.

I also finished the NHibernate documentation on the return flight.  Very good stuff.  After reading it, all of the stuff that I was struggling with the first two times around made much more sense.  NHibernate is perhaps too flexible and powerful for its own good; it offers so many alternatives to get at the persisted objects, that it really takes a lot of practice and study to figure out the use cases for each of the different access methods.

The only part of the documentation that I was really disappointed with was the tools portion; it was pulled directly from the Hibernate documentation and still referenced Java command line instructions and what not, which is obviously disappointing since it raises the question of where else the documentation could be wrong with respects to differences in Hibernate and NHibernate implementation and syntax.

NHibernate, at this stage, does almost everything that DLINQ does (from the early documentation that I've covered) with respect to ORM with the obvious exception of language integration (they'd have to write a custom compiler or comipler extension to get that).

Sooo psyched about the New York International Auto Show this year.

Nissan will have a big show there with the unveiling of the new Altima, among other things.

To get ready for this event, I put together a gallery of the shots from last year's show.

Enjoy!