Hi, I'm Ron Cormier. I'm the owner of a small software company where I design websites and build reusable web applications.

This blog is a work in progress but I plan on writing about website development, software design, information technology, and some of the projects I'm working on for Communicate Solutions. Check out my company's website, Communicate Solutions.com.
Sign in

Tags


So, as I mentioned in my last post, I've been  working on authoring a Windows Installer package for ePortfolio using WiX.  It has been an interesting experience.  Here's a short list of advantages/disadvantages:

Advantages:

  1. XML schema describes itself well and is well suited to this sort of authoring.
  2. Much more control over the features/functionality available in the installation package.
  3. Fairly active user community.

 

Disadvantages:

  1. Most of the documentation was written for WiX v2.x.  The current WiX version is 3.0.4318.0.  While the core seems to have remained stable, many of the supporting features are not well known/documented.
  2. Steep learning curve for those who aren't familiar with Windows Installer technology (MSI). 
  3. IIS virtual directory installation is severely lacking, particularly for XP machines.

 

I should expand on the third disadvantage.  In WiX, there are three things that identify a website in which you want to create a virtual directory: an IP address, port, & host header name.  If you want to create a virtual directory under an existing website, you need to specify each of those three pieces of information.  Pretty simple, right?  Well it is fine for production websites running on the Windows Server operating system since multiple websites can be running at the same time, and, since they're production websites, they can easily be configured to use host header names.

The problem is on my development machine, which is Windows XP Pro SP2.  First, on XP, you can't have more than one website running, so it's pointless for each website to have it's own host header name.  For example, when I'm working on client X's website, I start the website in the IIS snap-in and browse to http://localhost.  When I need to work on client Y's website, I stop Client X's website and start Client Y's website with the snap-in and again browse to http://localhost.  I imagine this is how most developers work; am I wrong?  Leave a comment below to let me know...

Given this XP scenario, the three WiX parameters aren't enough to identify a particular website since none of the websites use a distinguishing host header name.  WiX simply installs the virtual directory into the default website; it doesn't know what else to do! Yell  I understand that I could add a hosts file entry for each environment but that's something else I'd have to manage on my machine and my clients' machines.

To get around this shortcoming, I needed to break out my C++ IDE to write some custom actions.  In the end I need virtual directory creation to work on both XP & Server 2003.  The result was a solution which is similar to the installer packages created by Visual Studio.  It was a lot of work to achieve the default behavior, but I now have full control of the source code and understand what's going on behind the scenes.

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

It's been a while since I posted so I wanted to give everyone an update on my latest project.

As you may or may not know, my company, Communicate Solutions, is in the process of releasing a shrink wrapped software product to the world. The product is our home-grown content management system. The content management system (CMS) is named "ePortfolio" since it easily allows the creation of portfolio websites... you know, those websites which showcase the project work that a company/individual has done in the past. The software consists of a custom designed website and an admin site. Someone can describe a project and upload pictures of their work by using the admin site and these updates are reflected on the custom site. It does a bunch more useful stuff too; if you're interested, read more here.

Anyway, an important part of any piece of software is the installation and configuration of the software. The first thing a potential user/customer does with a new piece of software is install it. If the software doesn't install properly and work perfectly out of the box, you're in trouble. You only get one chance to make a first impression. I believe this is especially important for non-enterprise software.

Knowing I needed an installer, I started evaluating tools. I've used Visual Studio setup projects before so I knew they wouldn't quite give me the full set of features I want. I also researched some of the big-boy package creation software vendors like Wise and Installshield but they are not only expensive ($400 min), I felt like they would mask some of the complexity that I would need to understand in order to build a high quality package and troubleshoot any issues that may (will) come in.

I decided to go with a tool called WiX 3.0.  WiX is free, open source software which lets developers build installer packages by authoring an XML file.  I'm not finished building the installer package for my application but it is clear that WiX is quite powerful.  With that power comes quite a bit of complexity.  The learning curve is quite steep because WiX markup compiles to build MSI files.  That means you have to understand the rules of MSI in order to author a proper installer package.  Believe me, this is no small task.  There are a couple other nuances which add to the complexity of authoring an installer package with WiX; I'll go into more detail in my next post.

For now, here's a few useful links for authoring an installer with WiX:

  1. MSDN's Windows Installer Database Table Reference
  2. Many posts on Alex Shevchuk's blog, including this on explaining how a package gets installed.
  3. The original WiX tutorial by Gábor DEÁK JAHN

 
I know I'm going to struggle through a few more things, but I'll be much more confident in my ability to support the finished product because I'll understand the technology at its base level.  Wish me luck completing this project!  I'll be sure to post my lessons learned

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5