May 2010 Blog Posts

If you’re implementing a ListProvider for your Vail Add-In (more about the awesomness of that in a later post), you’ll quickly figure out that the Vail Dashboard now remembers ListView column configurations between sessions.

That means if you turn a column on (or off), or change the sort order, Vail is going to remember your changes and display your Add-In the same way the next time you open the Dashboard.

This is really annoying if you’re developing an Add-In and making changes to your ListColumnCollection.

The quick and dirty method to reset columns in the Dashboard back to their defaults (thank you, Process Monitor) is to delete the following file:

C:\Users\Administrator\AppData\Local\Microsoft_Corporation\Dashboard.exe_<snk>\<version>\user.config

The next time you open the Dashboard you’ll have default columns again.

Of course, this should not be done outside of your development environment. I haven’t noticed any issues caused by doing this, but your mileage may vary; we don’t know enough about the contents of user.config at this point, so doing this on a production server will probably have other consequences.

The Windows Home Server “Vail” preview is here. There have been lots of in-depth technical reviews of the new and updated bits in Vail, which is not surprising given how anticipated the new version has been.

The new functionality and improvements to the basic Windows Home Server infrastructure look great. I’m especially pleased that DE v2 now operates at a level below the file system; it’s going to be much more robust. Bye-bye file conflicts!

Of course, what really piques my interest in Vail is the new Software Development Kit. We’ve already seen a few previews and guides from the community on the SDK in Vail.

I’ve talked about what I think of the WHS v1 SDK in other places, suffice to say that it’s pretty rudimentary. There aren’t lots of bells and whistles in the plug-in model; really, you just provide WHS v1 with a WinForms control and you’re responsible for handling everything after the initial load.

So, after having played with the Vail SDK, what do I think? If I had to use two words, they’d be pure awesome.

My top 10 list of awesomeness:

  1. Magic WCF connectivity between Add-Ins, the server, and clients
  2. Magic INotifyPropertyChanged data binding for lists of business objects
  3. Core Add-Ins in Vail use the same Providers and SDK components as your code
  4. Core Add-Ins in Vail can be extended by adding your own tabs
  5. Core providers in Vail can be replaced entirely by your code
  6. Access to the Windows Server 2008 R2 SDK
  7. Remote Access web application can be extended
  8. Client-side Launchpad can be extended
  9. Health monitoring is a first-class citizen of the SDK
  10. Documentation

The last point is especially important; it took a long time for the community (and Microsoft) to develop decent documentation for WHS v1 Add-In development. Now, even the beta Vail SDK ships with proper documentation for all components and an end-to-end walkthrough of creating an Add-In from scratch; looks like I won’t have to go through a massive screenshot exercise this time!

I’m very excited about the SDK, as you can probably tell. Microsoft have put a lot of effort and thought into making Vail as extensible as possible, and it’s going to help 3rd-party developers make some really cool new toys for Windows Home Server.

There’s going to be a learning curve, of course. WHS v1 Add-Ins don’t “just work” in Vail, so you’re going to have to do quite a lot of conversion and re-architecture. But trust me, it’s going to be worth it when you see just how clean everything becomes in Vail.

Or, how to avoid embarrassing bugs in Disk Management caused by Turkish localization.

There’s a classic string localization problem in .NET development known as “The Turkish I”; there are two different versions of the capital I character in the Turkish written language, and they are not equal. Basically, if you’re comparing strings for equality, you’re going to run into issues if you do something like this:

if (string1.ToUpper() == string2.ToUpper())
{
    DoStuff();
}

In Disk Management, I was matching the string “\\PhysicalDisk0” to a variable, and forcing ToUpper() to make sure case wasn’t a factor. The result of ToUpper() on the Turkish string gave me a dotted capital I, which, it turns out, doesn’t match.

A lot of things in Disk Management depend on the physical disk number. If we can’t find a match, just about everything breaks.

So, what should we do instead? Well, I’d like to introduce you to Tentacle Software’s first mandatory coding convention:

public static bool CaseInsensitiveStringMatch(string string1, string string2)
{
    return string.Compare(string1, string2, StringComparison.OrdinalIgnoreCase) == 0;
}

Which works great. Basic stuff, I know, but it doesn’t hurt to be reminded sometimes that the basics still need to be taken care of.

Search

Site Sections

Recent Posts

Archives

Post Categories

WHS Add-In Tutorial

WHS Blogs

WHS Development