So many things have changed with the UI Framework 2009.1 release it's mind-boggling.  One thing that often gets overlooked in product changelogs or feature lists is the installation package itself.  I'll attempt to go over some of the changes we've made to the installer, and why we decided to do so.

The first thing you've probably noticed is that the number of installation packages has decreased from 12 (or 13 if you include the Silverlight beta package) to 1.  Obviously, realigning our AJAX offering to include the Web.UI, Chart, and Gauge products was the prime motivator for this.  As we started down the road of integrating those product lines, and the SOA.UI product became more fleshed-out, it seemed natural to include everything in one package rather than having a Silverlight package and an AJAX package, both with the SOA.UI product included, or have SOA.UI as a standalone package (which really makes no sense when you think about what SOA.UI does).  Once we decided to have a single, unified installer, everything fell into place.  What we ended up with is, I think, a much more simple, efficient installation experience for end-users.

Of course, one of the concerns of moving to a unified installer is the size of the package itself.  We made every effort to reduce this as much as possible by:

• completely reworking the Live Demos
  
• removing the .chm-based documentation files (we used to include both .chm and Help 2 .Hx* files)
• only including help files for a single framework (2.0 AJAX, which is the superset of frameworks from a documentation point of view)
• shipping a single License Manager for all products (facilitated by the implementation of a single, framework-wide license key)
  
• having the installer be smart about duplicate files we're shipping

So we end up with an installer of roughly 65 megs.  No bad considering what where replacing, and I believe one of the smaller integrated installers in the industry.

We also took the opportunity to rework some things in the installer that we never really liked.  First was the concept of a "Server" install type (as opposed to "Complete" or "Custom").  This option was included in previous versions as a convenience, and basically copied the product dlls themselves, plus a copy of the License Manager to the filesystem.  For some of the things we wanted to achieve, it became apparent that this installer should target a developer workstation only.  Developers create solutions there, and then deploy to the server (along with a .lic file for licensing) via xcopy of some other method. We kept this developer-centric mindset when approaching all features of the installer.  In fact, we might as well have called the distibution package "ComponentArt.UI.Framework.2009.1.DeveloperTools.exe", but someone thought that was going overboard.

Also gone are the automatically created IIS virtual directories for Live Demos.  These have been problematic in the past for a number of reasons.  We rely on InstallShield for creating and managing these virtual directories at install-time.  That product is pretty good in this regard, but there's no guarantee you'll get what you want if you're running on Vista, Windows Server 2008, or some other OS with IIS7.  We always included a fallback to Cassini (or WebDev.WebServer.EXE, or whatever it's called) in the event that the target machine does not have IIS installed.  So if we're confident that we're installing on a developer workstation (which we now are) then we know Cassini is available and launch that when we start the Live Demos.  We even designed a cool little app to manage the Cassini threads (it's available off of the Start menu if you have Live Demos installed).

Since we're so confident that we're now installing on a developer workstation, we decided to remove the option for "Visual Studio Integration".  Now you get integrated whether you like it or not ;-)  This includes VS toolbox items and help collection merging, and is why you have those VSPackage.* dlls in the product directory structure.  Essentially, we just couldn't think of one good reason why a developer would not want this stuff available.

There's a lot more that I'll try to address in future posts (the new licensing scheme, etc.). For now, please enjoy the new car smell!