I posted last year about the home network that I had built. It was actually a fair bit of work and somewhat expensive to get the base network and the initial set of drops setup. It also required a fair bit of thinking and up-front design to get the network structured in such a way that it would work for my up-front needs, and then would scale for new scenarios that I could imagine. It may seem like the task is really simple, and it kind of is on the face of it.

The difficulty is that you need to think through how many CAT5e/6 cables that you string between major areas of your house. For example, my cable modem and HDHR devices are in my garage (where my cable comes into the house), my gigE switch, a bunch of machines and my VOIP box are in my basement, and my wifi AP is in my attic. That may sound horribly bizarre, but each device is really in the best location for its purpose, and I needed to ensure that I had enough cable going between locations to handle the neccessary connectivity.

That also doesn't count that I am running voice (voice originating from my VOIP box) throughout the house over some of these lines, which means that I have to add another line for analog voice between the major areas of house beyond what I need for the IP network.

My point in this post is that after nearly a year, I decided to add three more drops on the top floor of the house. Other than the requirement to crawl into the corners of my attic for one of the drops, it was really, really easy to tie into the base network that I'd setup months ago. It was very clear what I needed to do to tie into the network, and it all worked the first time.

In addition, I decided to hook up all three of the new drops for data for now, but it will take me just a few mins to 'downgrade' one of them to voice should I want to. It is really nice to have that degree of freedom w/o having to re-wire or otherwise re-do any of the work that I've done. 

Lately, I’ve been thinking about the overall .NET deployment and servicing story. There are a number of aspects of deployment that one can consider. The particular issues that are salient for your product depend a lot on the kind of code you deploy onto end-user machines.

First, let’s look at the different kinds of products that developers might build, and need to deploy:

-          Monolithic applications

o   A single exe that is not dependent on any libraries, other than the .NET Framework itself, or

o   Solely dependent on libraries that are serviced/upgraded with the application

-          Aggregate applications

o   Dependent (at least partially) on libraries (or controls or components) that are installed/serviced/upgraded separately (in ‘time’ and/or ‘location’) from the application

o   These libraries are likely sourced from a 3^rd party

-          Components, controls or class libraries

o   You build assemblies that other developers reference in their applications (both ‘Monolithic’ and ‘Aggregate’ applications as described above) or other libraries

While we’re thinking broadly, one is left wondering what the critical questions are to think about for each of the deployment cases above. There are a lot of questions that one can imagine looking into. They range from .NET Framework and application deployment, to servicing multiple versions of your applications out in the wild, to safely deploying a new version of your API (class libraries) onto end-user machines w/o any adverse impact.

The first one that I’d like to look at is: “Am I building my product correctly for the future?” This question, though, really boils down into two important questions:

-          What do I need to think about when shipping v1 of my product?

-          What do I need to do to safely, correctly and seamlessly ship v2 of my product?

Those questions seem very simple, and they are on the surface. The answers are not overly complicated, but do require some up-front thought to ensure that you end up where you want to.

We have had folks come to us after a successful v1, not quite sure what to do for v2. You may be wondering what the crux of this is … you just hit ‘go’ on csc/vbc another time and you’re done, right? Maybe. It all depends on how you want your code to behave when you ship your second version.

Note that I call out v2 specifically (and not v3 and v4) since v2 is the first version after your initial one, and will be the time when you need to address any issues that come up with shipping again. Once you’ve got a plan in place, you’ll be able to rinse and repeat for each subsequent version (provided that you have a good plan).

In my next posts, I’ll answer this question for each of the product types listed at the top of the post.