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.

I finally decided that it was time to get a real network setup in my house. I had some one-off network segments around the house for particular purposes, but not a real whole-house network w/a set of primary interconnect points, in addition to CAT5e drops around the house.

This project really started this summer when we had the house painted. I ripped off (imagine a violent action) all the coax and phone cords off the side of the house prior to the painting, both to ensure that the paint got under the wires, and to remove them permanently. I bought an HDHR at the same time to enable a new cable connection to my TV, over one of the network segments that I mentioned earlier. That worked out nicely. Still, I wanted to be able to use my HDHR on any PC in the house, and that's kinda difficult to reliably over 'g' wireless. Others may argue the fact, but try viewing HD content, and you'll see that 'g' falls on its face for that application, particularly if you have multiple streams going at once. I could have gone 'n' and will, but I really wanted to get a gigE network up and running, since it is fast and reliable.

I also should note that my existing phone network had already proven to be pretty bad. So, I already had an existing need to fix that.

Off to Home Depot, which is pretty much the answer to all issues relating to the home. Come back with 1000ft of riser CAT5e, 50 RJ45 connectors, a Ideal crimper and and Ideal LinkMaster CAT5 line tester. I also bought 8 large pieces of drywall, wood, some insulation and a whole ton of other odds and sods, but that is indeed another project.

I'm finding that cutting (to length) and crimping CAT5 is something of a challenge. It is conceptually simple, but I appear to be still mastering this task. I've made a bunch of mistakes, such as not following a wiring standard at first (even though I've used them before for my earlier network segments), mistaking the pin order of the connectors, and then incorrectly ordering the pins once I'd chosen T568A as the standard to use. The test tool is kinda neat since it tells you exactly where and how you've messed up. This is pretty useful if you've got a 50ft segment from your basement to your attic that isn't able to create a connection.

When I'm done, I'll have both a new phone network (over CAT5) and data network. The phone network actually only uses 1/4 of a CAT5 line, but that's OK. The 'backbone' is two CAT5 (one data, one phone) lines and one additional CAT5 line that I may need later for some unknown reason. Every drop (phone or data) connects to this backbone at one of three interconnect points (garage, attic and wiring closet in the basement). This allows me to easily add machines, NAS, APs and pretty much any other kinda IP appliance (like the HDHR) at any point in the network.

My neighbor, who is in his 70s, keeps making references to me being able to "run Microsoft on this network". It is pretty funny to hear that viewpoint. I'm sure that there is more XBox Live traffic during the day on the internal MSFT network than my wee network would ever be able to handle, except maybe on Christmas day ;)

More Silverlight exploration.

I want to create a user control that has the concept of children that I can add (this.Children.Add()). I see that Panel adds this concept, but that Control is missing it. At the same time, Control provides the InitializeFromXaml helper, which seems to be pretty integral to user controls. Panel and Control are completely disjoint (in terms of inheritance chain), so you cannot nicely merge these two.

What are folks expected to do in this situation? Good question. The team is aware of this, and working on a solution. In the meantime, you (and me) will will need to do some hacking to get the control children outcome.

I had a strange (and not particularly pleasant) morning today, so I quickly decided as I entered my office that I wouldn't be doing any work this morning. Time to open VS and kick on Silverlight a bit more.

I'm thinking that the task for the morning is to write a fancy Image subclass. Sit down, new SL project, add a user control and add ": Image" to my class declaration. Turns out that doesn't work. Huh?

I open up the object browser, and System.Windows.Controls.Image is 'sealed'. Ouch! You have to subclass Control, or MediaBase. This isn't the experience that I was looking for. Hmm. Answer: Send mail ...

From: Richard Lander
Sent: Tuesday, September 11, 2007 10:50 AM
To: Rich's Buddies in Jolt team
Subject: Image is sealed. Why?

I was noticing that all the end-point classes (Image, Textblock, …) are sealed. What’s the thinking on that? It definitely inhibits the developer experience.

rich

I'm still waiting back on the final answer, but I'm guessing (and hoping) that this is issue is a bug. It has to be.

I also noticed someone else running into a variant of this issue.

I'll keep on pusing on this one.

I imagine that most developers when presented with the concept of Silverlight have a very joyous first response. And then the next thought is a pragmatic one of wondering how much code (source or binaries) can be shared between Orcas and Silverlight. In the past, I've come across some pretty interesting uses of ASP.NET to share experiences across both the server and the offline client. Today, I'm pretty sure that we can offer a better scenario than that.

Before we go into details, let's talk scenarios. My dream scenario is that TurboTax would move their web-based version to Silverlight, and their client version to full WPF. For the Silverlight version, I'm thinking of a pretty immersive application, along the lines of the nibbles tutorial or the new Tafiti search app. I can easily see a major improvement in customer experience, including for me, a multi-year TurboTax customer.

The question on the table is the degree to which Turbotax developers (for my dream scenario) could share code across those two presentations of Silverlight. There are two parts of that: the UI layer (WPF code, xaml and other assets), and then the business logic. Although possibly the most interesting topic, I won't address the UI at this point since the WPF and Jolt teams are still working out the kinks on that issue. The business logic aspect of the issue is well within the purview of what I've been working on.

Our goal for business logic has been pretty simple: subset the existing Orcas stack for the BCL, XML and other base technologies in a very, very compatible way. We want folks to be able to take their Silverlight business logic, and re-use it on the desktop. For Turbotax, you could imagine them being able to port all the code that calculates your taxes against the static IRS tax tables to Orcas. At this point, we're focussed on making source re-use work really well. Binary porting is definitely something that's on our list, but not what we consider to be the mainline scenario since you'll need to re-compile your UI code anyway. I'd like your feedback on it if you have a differing opinion.

You might notice that I'm talking about porting code from Silverlight *to* Orcas. The reverse direction isn't nearly as compelling. By definition, Silverlight will always be a subset of Orcas, and your Orcas code may have a lot of dependencies on types that are only part of Orcas. Starting from Silverlight, you know that all of the APIs that you use will also be on Orcas, and you're experience porting to Orcas will be straightforward.

One kink is that we've added APIs to Silverlight that are not in Orcas. So, my story as described above is actually a little flawed. Naturally, we'll add those to the next desktop release after Orcas, but there is a question of how to deal with that in the meantime. We do have a solution for that that we're working on. I'll post on that when I have firm details available.

Judging by the search engine traffic to my blog, it appears like folks are still looking for gacutil!

I wrote this post almost 2 years ago, relating to Whidbey, and the location of gacutil at that time.

Gacutil, and the rest of the SDK, has moved again. You can install it with VS 2008 or separately. In either case, once installed, you'll find it on your disk @ C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\gacutil.exe.

BTW: The .NET Framework SDK now has a new name, so searching for the .NET Framework SDK doesn't work as well now. It is now called "Microsoft® Windows® Software Development Kit (SDK) for Windows Server® 2008 and .NET Framework 3.5".

I've been using Terminal Services (AKA 'Remote Desktop') since I started working at Microsoft in 2000. Back then, we were using Windows 2000, natually. After having used the 9x family of Windows since Win 3.1 (and DOS before that), the whole concept of 'TS' seemed pretty incredible. Yes, I'd used similar facilities on other OSes, such as Solaris, but never on Windows.

Windows Server 2008 brings along with it another similar and related breakthrough. It's called RemoteApp. Instead of remoting a whole desktop, it remotes an application. The initial logon process is very similar to Remote Desktop, but after that, you really do have a window that operates just like any other window on your desktop. There are some aspects of 'remote-ness' that leak through, but they are far, far, overpowered by the utility of the feature. Also, you don't need to logon for each window, just once for the machine from which the RemoteApps are remoted.

I've been dogfooding this feature for a while, and I find it incredibly useful and productive when working from home (which I do a fair bit -- like right now). Imagine having a RemoteApp IE window on your desktop that is on your corporate network. You have your regular IE on your desktop that you use to view random web content, and the RemoteApp IE that you use to browse your corporate network. This is super useful for sharepoint sites on your corporate network.

Next step is to convince (A) your CFO to buy a bunch of Windows Server 2008 boxen, and (B) get your admins to turn on this feature.

The comments on yesterday's post on compatibility are pretty interesting.

There are effectively four options available when you find yourself a few versions into a platform and realize that you've made mistakes:

1. Keep the mistakes, and potentially propogate those mistakes into other parts of the platform
2. Rip out the mistakes, re-design the feature (sans mistakes) and accept the breaking change and broken apps
3. Re-design the feature without the mistakes, add that re-designed feature to the product, deprecate the old broken feature, and accept duplication for some period of time until the older feature is ripped from the product
4. Re-design the feature, add some elaborate compatibility mechanism to emulate the old behaviour, and sign up to maintain the elaborate compatibility mechanism for a long time

There may be some other options, but these are the ones that come to mind.

The comments from yesterday were in favour of (2).

I'm in favour of (3) as the primary model for making the product better, with a little bit of (2). I'm also willing to accept some of (1). I really dislike (4), as it doesn't benefit anyone in the long-term. (3) works well for individual APIs, but doesn't work well for whole sub-systems, such as the loader. If you change the loader in an incompatible way, you're really looking at options (2) or (4).

We've actually made a bunch of changes in Silverlight to improve the platform. As examples, we've removed non-generic collections, and have changed the way String comparisons work. We also changed the binder pretty significantly. Not to mention a new security system ... Oh, and we also included a stripped down XMLReader/Writer!

Compatibility is a tough balance relative to product evolution. We've been discussing this exact issue a lot over the last year, and the best way to evolve the project forward. The trick is coming up with a model that you really life, doesn't hugely impact the engineering process, doesn't inhibit product evolution going forward, and is explainable to customers. Taking submissions now ...

I was just reading an Old New Thing blog entry about compatibility. I get the point that Raymond is making about compatibility. It reminds me of a lot of conversations that we have in building 42.

I talk to folks with the same proposal of pulling out the 'compat crap' to make the product better. I have two thoughts on that:

• We'll be having this same conversation one release from now when we've implemented and shipped another set of designs that you don't like, when looked at in hind-sight
• There are a ton of folks that have invested a ton of time and their livelihood into the apps that they've bet on our platform. What do you want me to tell them?

Compatibility is feature number 1. Without it, you don't have a product, at least for very long.