Geeks With Blogs
Mike Huguet I'm just talking out loud

Any of you ever installed a distributed multi-machine system? How did you do it? Did you use an off-the-shelf (OTS) product such as WISE or InstallShield? Well, my company was faced with this decision last year. Here is my story, but I'd like to hear yours.

The company that I work for recently released our newest product that is a highly distributed Windows system with tons of C++ COM dlls, DCOM proxies, Registry entries, message queues (MSMQ), Services, .NET Interop, and lots of databases (including Transactional and Merge Replication...my favorite). Not only are there a lot of system components, but the architecture allows for the subsystems to be installed in many different machines configurations having them spread accross machines supporting scaling out.

I was in charge of heading up the installation effort. It was probably more out of convenience than anything or possibly because the search for an InstallShield contractor turned up empty. Regardless, I was on a mission to come up with a solution. With the little InstallShield experience that I had (a painful experience at that) and learning from one of our other product's maintenance woes with this OTS product I did a little bit of research and a fairly simple feasibility analysis. Because of the distributed nature of our system and the lack of an installation management army (I mean team) it seemed like there must be a more manageable solution.

Here were some of the options that my research turned up:

  • Use an OTS product such as WISE or InstallShield
  • Use VS.NET installation project(s)
  • Use MSI directly
  • Use the WIX toolkit, http://sourceforge.net/projects/wix/)
  • Use a custom solution (developed internally or outsourced)
I spent quite a bit of time educating myself on VS.NET installation projects, MSI, and WIX. It quickly became apparent to me that installation management is definitely a full-time profession and that I was glad to be in a more general role in my current job. Bless those that are in this role in their organization! After weeks of the Discovery phase, some proof of concepts, and many meetings we decided to develop a custom solution internally. Here are some of the reasons for the decision:
  • In order to fulfill all of the requirements the other solutions would have required a lot of custom development anyway.
  • There would be a learning curve in extending OTS products such as their scripting languages and MSI such as custom install actions.
  • WIX had great intentions and would work well for simple applications, but still dealt with the shortcomings of MSI.
  • There were no affordable external resources available for assisting us with the other options.
  • There were no plans for new full-time or part-time installation management personnel
  • The big things were that we needed lots of control over the maintenance processes allowing for simplified installation and update management and integration into the current configuration management processes. Each of the other solutions met some of these needs, but not to our liking.

The implementation was planned in three phases allowing for more manageable milestones, quicker testing, and earlier usage of the installation for internal deployment. The three phases took about five months to complete including design, implementation, and test/fix iterations.

Implementation Details:

  • Developed primarily in C# (v1.1 .NET Fx) with some C++
  • Three subsystems: Designer, Build, Runtime
  • Designer has an IDE like UI that allows for configuration of the system's installation. XML Metadata is managed by the Designer and stored in Version Control. The usage of Version Control allowed for easy integration into our current configuration management processes which have branching and defect tracking built-in.
  • Build integrates into our code build process converting the design version of the metadata into the runtime version as well as custom compilations to perform actions such as dynamically adding dependent files.
  • Runtime is the engine that drives the installations and updates. It also has some nice extended features such as remote machine updates and current installation image verifications.
  • Used .NET Remoting for cross machine and process communication

I would be lying if I said that this was an easy implementation. There were quite a few challenges especially in the COM Interop area with issues such as file locking and randomn crashing. After overcoming these things everything just fell into place. After much testing and tweaking the installation system is pretty sound and highly extensible. My bosses, Implementation, and the other team members seem to be pleased with the results.

What are your solutions?

Posted on Tuesday, September 27, 2005 9:12 PM Architecture | Back to top


Comments on this post: Installing Distributed Systems

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Mike Huguet | Powered by: GeeksWithBlogs.net