Bit-Shift.Net

This past April I took the plunge that so many young people anticipate, dread and dream about all at the same time. I bought a house. It's a 3 story town house with a single car garage. Not the Taj Mahal by any stretch but my car and bike fit in the garage, I have a place to sit while I eat my meals and I'm totally in love with my next door neighbor (yes she knows and the feelings are mutual). And, the house came pre-wired with CAT5E. Most rooms have two ports, while the others only have one. In total, there are 11 ports throughout the house.

When I first moved in and saw a patch panel in the closest in one of the master bedrooms, the computer geek in my instantly though, "I need a wiring closet!". Unfortunately when you buy a house, you also have to furnish a house. When I moved in I had a bed and dresser to my name (I moved all my worldly possession in under 3 hours and most of that was driving).  But the idea never wandered far from my mind and a few weeks ago I finally got all the necessary hardware together.

For handling all the network connections I chose the Netgear GS116 desktop gigabit switch. It was fairly inexpensive after rebates from Netgear and Paypal, had enough ports to handle the job and had the mounting holes I needed to secure it to the metal plate that covers the patch panel. The router, a D-Link DIR-625,  I have had for almost a year. I bought this router after my Linksys died and my friend Greg gave it a fairly glowing review and I must say I'm 100% satisfied with it.

Up till I finished the install, my wiring closet would probably garner a top ten spot in a worst installation contest. I had the cover of the patch panel off and power cords and CAT5 running up to a shelf where my wireless router sat routing my packets, blissfully unaware of the squalor conditions in which it lived. Every time I walked into my office, I saw the eye sore that was my network installation which motivated me all the more to finish the installation.

Now being an engineer, I couldn't just throw everything together with chewing gum and bailing wire, I needed a plan or a template rather. My plan was to mount the switch and router to the metal plate that covers the patch panel and run the CAT5 wires through the plate to the patch panel. The next major hurdle was how could I layout where everything would be mounted and where the wires would be run in a fashion so that everything would look great and I would drill 50 holes unnecessarily trying to get everything lined up. Back in high school, I took a class on drafting using AutoCAD and thinking back, that seemed like the best option for creating my template as it would allow me to draw with the precision I needed when laying out where all the holes would be drilled.

After about a month of tweaking the templates so that everything lined up just how I wanted it I was ready to drill the holes and mount the hardware. To make sure that all the CAT5 cable lined up in an aesthetically pleasing way, I used zip ties to secure the wires, which meant I had a lot of holes to drill. After drilling, I used a metal file to ground down the rough spots and got the plate ready to install the grommets that will protect all the wiring from sharp edges.

As I suspected, the hardware mounted right up with a minimal amount of coercion. The next time consuming chore was crimping all the CAT5. I had the 11 ports from the switch to the patch panel, a cable connecting the switch to the router and then a final cable connecting the router to the world. Amazingly enough, I only had to re-do one cable. With all the wires run and the hardware mounted, I re-attached the plate to the patch panel and proceeded to surf. I have yet to run any bandwidth tests as I only have one gigabit enabled computer.

So there you have it. I have gigabit running through my home which will come in very handy when I build my home theater PC or buy an Xbox 360, which ever I decide to do. And as an added bonus, since I run a home based business, I can write the switch off as a business expense.

Intelligent Authentication (IA), the product I help develop, has for the past few versions been installed through the use of five .NET setup projects (one database and four binary installers). For anyone who has to do application deployments on a regular basis this is far from an ideal approach, even bordering on painful. From a development standpoint this is equally as painful. The .NET setup projects that ship Visual Studio.NET 2003 are a clumsy bastardization of Microsoft Installer (MSI) technology. Imagine if you will MSI, a 10,000 fingered glove allowing you to poke, prod and massage a target computer for deploying your application. Now the .NET setup projects that ship with VS.NET takes those 10,000 nimble fingers and reduce them down to five rather awkward and bulbous fingers. Causing anyone who has dealt with them to consider throwing themselves in front of a bus. But I digress.

Over the past few weeks I have condensed those five installers into two installers (one binary and one database) using Installshield 11 basic MSI projects. As part of the IA binary installation, I set some data in a config file. If IA is installed on multiple servers (e.g. a web farm) this data would need to be replicated to each server's config file, a very error prone process for us humans. To automate this task I dump the data out to an XML file for easy transport and have the installer allow the user to browse for this XML file during auxiliary installations of IA. Piece of cake, right? Not so apparently.

There doesn't appear to be any built in file browsing functionality in the Basic MSI projects. I later found out that this functionality exists in the Universal installer projects, but I'm too far along to start over. So the answer that a co-worker and I came up with was using a custom action to call .NET code.

I make extensive use of custom actions in my installers to do all sorts of things ranging from validating domain credentials to creating application pools and virtual directories. I created a file browsing dialog in C# using the OpenFileDialog class and call that code from Installscript through COM interop (it's not as painful as it sounds).

At Corillian we already had an existing class library project containing various utility classes for use with installers. I added a class to that project for holding the logic used to pop the dialog. To make this class available through COM interop, you will need to add a couple attributes to this class and include the interop name space.

using System.Runtime.InteropServices;

namespace InstallerUtilities
{
[ComVisible(true)]
[ClassInterface(ClassInterfaceType.None)]
[ProgId("InstallerUtilities.FileTools")]
[Guid("0ec929cd-5135-441a-98df-10f227f3afc8")]
public class FileTools
{
   public string BrowseForFile(...)
   ...

Inside the class you will need to add a method that actually spawns the OpenFileDialog. To call this from InstallScript use the CreateObject function to create an instance of the new class, passing the ProgId you specified in the attribute (e.g. "InstallerUtilities.FileTools"). Once you have a handle to FileTools object, call the BrowseForFile method and viola, there is a file browsing dialog.

One undesirable catch I need to mention is that the OpenFileDialog will open behind the main installer window. To make the OpenFileDialog open in the foreground took a bit of coaxing. There is an overload to the ShowDialog method of the OpenFileDialog class which takes an IWin32Window parameter to designate that dialogs owner (the installer).

To get a handle to the installer dialog we use a function defined in user32.DLL called FindWindow, brilliant huh. To use this method we have to add an extern reference to the user32.DLL like so:

[DllImport("user32.dll", CharSet=CharSet.Auto, SetLastError=true)]
public static extern IntPtr FindWindow(string ClassName, string WindowText);

You'll notice that FindWindow returns an IntPtr and we need an IWin32Window. Ryan Farley has a write up on his blog on how to convert an IntPtr into an IWin32Window by create a wrapper class that derives from IWin32Window. Call FindWindow, passing in null for the first parameter and the title to your installer dialog (usually the ProductName property + " - Installshield Wizard") for the second parameter. Wrap the returned IntPtr inside the WindowWrapper class and pass that to the ShowDialog method for the OpenFileDialog class. Your file browsing window will appear front and center for your end users.

To increase reusability I suggest having all the various properties of the OpenFileDialog class be passed in as parameters such as Filter, initial directory and Window Title (of the file browsing dialog, not the installer dialog).