So, it would appear the one of the pillars of the WiX community, Derek Cicerone, is retiring from WiX and moving on from MS at the same time.  I want to personally, publicly thank Derek for his enormous contributions to this effort.  WiX is typical of most open source projects that have success, in that there is a strong leader and a few key contributors that keep it going.  WiX has a thriving user community, but very few actually contribute to the code base and other key deliverables like documentation (me included).

When one of the pillars of an open source project steps down, it is always leaves a vacuum that is difficult to fill.  I'm sure things will continue to move forward, but it is always a little scary to image how things will be without that person.  Hopefully someone will step up.  It won't be me, so I'm lame.  :)

I've had a few personal email interactions with Derek and have always found him to be a good guy and have admired his leadership and style.  Good luck with your next endeavor.

So, why is an LDAP/Identity guy like me interested in an open source project that facilitates authoring MSI files for software deployment?  Is that a little out of your realm.  Well, as a matter of fact, deployment is something I'm really interested in and had to dig into pretty deeply for one of my projects at work.

My story involves the web single signon project that I was brought in to save 2 years ago when I took on my current role in my company.  It all boils down to having a package of vendor software that needed to be installed on IIS web servers to provide our own customized version of the vendor's software.  The software is a bit tricky, in that there is an ISAPI filter and a web service extension (IIS6 only!), a bunch of login UI pages, some home grown config tools and a Windows service that integrates with the web service extension.  It needs to support install, uninstall, upgrades and migration of settings from one version to another from a custom Apache-style config file.  It is non-trivial.  :)

During this time, I learned many important lessons about setup, most recently how important it is to use ALLUSERS=1 if you want per-machine installs (per-user installs, the default, results in chaos for server components when multiple admins perform tasks on the boxes!). 

I'm also the proud owner of a little component our company uses fairly extensively that is basically an HTTP Module that gets installed in the GAC, registers with VS.NET for "add reference" integration and installs an event log and source.  This thing was whipped up with VS, but I'm converting it to WiX sometime soon so I can get away from the dreaded installer classes (a topic for a different thread at a different time).

So, my angle on setup is really focused on deploying to the enterprise, not commercial software, and doing server side stuff, often with a bunch of .NET stuff, IIS integration and Windows instrumentation features.  At our company (and maybe yours too), we struggle to successfully deploy web apps, especially the complex ones, and have a mandate to make this easier for the admin.  As such,  I think this arc has a future in my career (although we've got a long way to go before this stuff gets institutionalized). 

Anyway, in other news on WiX, Jamie Cansdale (of TestDriven.NET fame, a fellow WiX user for his own product and a hell of a nice guy that I had lunch with at the last MVP summit on our way out of town) reports that WiX v3 may be adopted as the native deployment technology to be integrated into the next VS.NET release.  It looks like the VS team may finally drop their proprietary authoring thingy in favor of something more powerful and integratable (sic) into an automated build process. 

Good call guys.  I hope it works out.

(Update, ~2 hours later)

In going back and rereading Rob's original post, I think he was talking about the VS team's decision to build the VS installer itself with WiX, not an indicator the vdproj files will be WiX-based anytime soon.  Rats.  This is still a good thing, as strong internal commit to use WiX tends to assure some sort of a future (VS.NET, Office, SQL, etc.), but this would have been cool.

Maybe I've got this wrong and they'll shock us?  I think it makes a whole lot of sense, although this is a pretty difficult thing to convert from and a big jump for a lot of people.

The Problem

So, let's say you are building a claims-based application for Active Directory Federation Services (ADFS) and you want to use VS.NET 2005 to do this.  Alternately, let's say you are customizing some of the built in pages that come with the federation server or federation server proxy and want to use VS.NET for that.

As things stand today, there is a minor annoying friction point here as the ADFS installer doesn't provide a nice clean way to set a reference to the code you need in System.Web.Security.SingleSignOn and such.  Even if you are developing on a 2003 box (which a lot of serious web devs do, although I still stumble along with XP as its the company standard) and actually install ADFS, you don't see these assemblies in the .NET tab on the add reference UI.  The problem is that the ADFS installer puts the assemblies directly in the GAC and doesn't leave a copy on the "normal" file system (which the compilers actually need), nor does it bother to create a registry key under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx

(which is the little bit of magic that gets your assembly in the .NET tab).  Multiply this by a large team working on a claims app, and this can be a drag.

The Solution

So, what's a dev to do?  Well, you can definitely copy the assemblies yourself, GAC them and create a registry key and probably do all that with a little batch file if you are so inclined.  Or, you can go over the top and create your own MSI installer package that does this for you.

As a little experiment to see if I could do this quickly and learn how to do some new stuff in MSI that  thought I'd need later on, I did the latter.  It took about an hour over lunch one day.

I'd love to just distribute the msi package directly, but I won't consider doing that unless MS gives me permission to do so (which I don't expect to get).  So, that won't happen.  However, I will tell you how to build your own (fairly) painlessly.  For this, you will need:

Ingredients

• One copy of Windows Installer XML (WiX) 2.0 (3.0 might work as well, but I didn't bother trying)
• One copy of the ADFS.msi package that comes with R2 (dig around on the install media for it), or alternately, the 3 assemblies that come with ADFS that are installed the GAC that you hoisted from a normal install
• One copy of my sample WiX file that will create the MSI (see link at bottom)

Recipe

1. Place the vsadfs.wxs file in a new clean directory on your file system
2. Use dark.exe from the WiX distro to reverse engineer ADFS.msi in order to get its files into a handy .cab format, ignoring the error from Dark (<wixpath>\dark -x bin -out adfs.wxs adfs.msi)
3. Grab the three assembly files (S.Web.Security.SSO *) from the cab file and stick them in a directory called "files" underneath the directory where you put my vsadfs.wxs file
4. Run these two commands from the command prompt, filling in the path to your WiX binary install where appropriate (unless you have that on your path, obviously):
   1. <wixpath>\candle vsadfs.wxs
   2. <wixpath>\light -out vsadfs.msi vsadfs.wixobj <wixpath>\wixui.wixlib -loc <wixpath>\WixUI_en-us.wxl

You now have a working msi installer that will install (and uninstall and repair!) these things for you.  You may notice that the UI thing I used, WiXUI, shows a license screen and shows the CPL license there.  That's because we didn't supply a license.rtf file in our directory, so WiXUI picked up the one that comes with WiX in its directory.  Feel free to change it.  If you want to eliminate that dialog completely, you are on your own.

Caveats

• This will NOT give you a working version of an ADFS-enabled web server!  You cannot use this to actually generate a SingleSignOnIdentity object to be used for testing.  You would need some sort of a mock object thingy to do that for you (may that's next?).  All it really does is let set a reference in VS.NET and compile the code, but that's better than what you had before.
• Additionally, my current installer uses different component GUIDs for the version of the files that go in the GAC.  I'm not sure if it would be the right thing to reuse the component GUIDs from the real ADFS install which puts these components in the GAC or not.  The only time this might be an issue was if you ran this installer on a box that already has ADFS installed.  I'm not sure what would happen, but right now it seems better to keep them separate. 
• The installer allows specify the install location if you want to change it and breaks the VS.NET and GAC install stuff into separate features so that you don't have to install both if you don't want.  This can be customized via the feature tree dialog.
• The installer does not bother to check if you have VS.NET 2005 or even .NET 2.0 installed.  This would be a good sanity check for mass market usage, but I'm hoping the users of this are not too insane. 
• The installer defaults to a "per-machine" install instead of per-user.
• Repackaging Microsoft's installer is probably a violation of something and may void your warranty or get you in some sort of trouble that I had not fully considered when offering this suggestion.

The Future

I'm hoping that future versions of ADFS will have this scenario already considered so that things like this won't be necessary.  Perhaps we can convince the team to ship this as part of the product or as a free download/sample solution?  I wouldn't be surprised to see these assemblies in a future version of the .NET Framework as well, which would mean that we'd get this for free another way.  Until then...

(Updated 2 Aug 2006 changed to zip file)

I've been telling myself I was going to finally get into the blogging racket for almost 2 years now, but even though I've had the hosting all put together for that entire time, it took me forever to actually get it together.  I just had to do it myself instead of using another site...

Anyway, this blog will probably resemble the blogs I already read, in that it will be mostly technical with a focus on building software using Microsoft's .NET platform.  It will probably lean heavily on my specialties, .NET LDAP programming and application security, but will likely also feature other stuff I'm into like application architecture, agile development, identity federation, cryptography, and setup development in MSI using WiX. 

Speaking of .NET and LDAP, if you've ever heard of me before, it is most likely because you might have stumbled across one of the myriad usenet posts I've made over the last 4-5 years on the Microsoft newsgroups, or perhaps I answered your question directly.  Micrsosoft has actually designated me an MVP in this area, and I've even written a book about this with my intrepid co-author, Ryan Dunn, to further our aim of providing resources for the .NET community in this obscure, but stranglely difficult and increasingly important aspect of software development.

That's all for now.  Maybe some real content next time, eh?