ClickOnce ... Through the Looking Glass

By now, I'm sure my developer buddies that are versed in the Microsoft(r) paradigm have at least "heard" of ClickOnce.  That wonderful feature that was released with VS 2005, and has made many the small project ridiculously easy to toss onto a disc, push out to the company network, and even make it available to the general public.  Configurable, and fully operational, out of the box.

But what happens when your project domain requires that development happen behind the firewall, and installation of the completed project must escape the friendly confines of the company network, and venture into the hands of an external source control system, that lives beyond the firewall? What is a dev to do? The beauty of the technology is the ability to continually ensure that the end user has the latest bits.  But when the target machine is abstracted by this additional layer of complexity, things get a bit dicey, and a lot more challenging.

The scenario: A project is being developed on an internal company network, with the source code under a company approved source code repository.  Pretty standard stuff.  Here is where the wrinkle comes in.  Upon deployment, the installation bits must reside in an EXTERNAL repository, that is also version controlled..  Sound crazy, it's not. It really does happen.  So then, how can we take advantage of the simplicity of a ClickOnce deployment, in a complex environment like this?

First, let's set up the environment.  We'll need:

1. Source control for the code base.
2. Separate, external version control for the published artifacts
3. IIS running on both the local dev box, and the installation machine.

The key lies in the design of the ClickOnce feature set. This type of deployment is designed to function over the network.  Keep that in mind, as we move along.  Something else to keep in mind is that the local machine is part of the network as well (as a developer, I forget that part sometimes). And, as we are talking about developing in a Microsoft-based environment, let's also consider the web server (IIS) on the local dev box ("127.0.0.1" to be specific) as part of the network too.

So far, our environment looks like this:

So here's what we do with this setup:

1. Configure the local IIS with a virtual directory that points to a physical location on the local machine.  This location MUST be the same physical location that the application will be installed from on the client.  
2. In the Publish tab of the project Properties, there is a text box to define where the application will be deployed to. In that box, define the publish location as" http://127.0.0.1/<project deployment location>/". In doing this, ensure that IIS on the development machine has a virtual directory of the name that you want, and that virtual directory points to the actual physical location that the application will look for when it is installed.  This is important, because when the application is actually installed on the machine outside the firewall, it will look here to find the files required .  And if set up properly, the developer can publish to this location on the dev box.

From here, the developer can write code to whatever he needs, and throw it to the local IIS, and then take that and upload the changes to the versioning repository (no we are not going to get into the fact that ClickOnce handles it's own versioning as part of the publish process).

I'm sure with the ability of ClickOnce technology to be used just about anywhere, this use case may seem unnecessary. From my perspective, you would be right, and those discussions were many, and often.  In the end, this is what the client wanted, it works, and that's all  that really matters