Windows Home Server’s success as a platform depends entirely on the ecosystem that surrounds the product. That means the various hardware vendors, obviously, but it also means the software development community; both the big ISVs and as well as the single-developer shops cranking out Add-Ins in their free time.

In just about every major WHS update, Microsoft has extended the SDK for Windows Home Server. They may not update the SDK documentation, but there are almost always new bits of functionality or tweaks to existing capabilities. For example, Microsoft recently added support for programmatically changing Shared Folder permissions (see Part 3 of my WHS Add-In Tutorial), and we’ve seen the gradual clean-up of a bunch of existing methods in the main SDK (not having to call Init() on everything means less unhandled exceptions and less trips through the debugger, which makes everyone happier).

I really think that the Windows Home Server extensibility team “gets” the promise of the platform; the WHS SDK isn’t something they stuffed haphazardly into the product and then forgot about.

Now with Power Pack 2, we’ve been given even more toys to play with.


Programmatically changing disk location text

Based on feedback from various partners, Microsoft has added the ability to programmatically change the displayed value for the Location column on the Server Storage tab. You’re no longer stuck with “Internal (IDE)” or “SCSI”; you can set the value to any text string you like.

The method to change the value displayed in Location is exposed by the new IDiskInfo2 object. You can get at this new object using the standard WHSInfoClass.GetDiskInfo() method. In order to see the new IDiskInfo2 object in Visual Studio, you’ll need to grab a fresh set of Power Pack 2 assemblies from your server and change your project to reference the new files. And if you’re using ReSharper, you might need to kill the cache folder in the root of your project directory.

To set a new value for Location, just change the LocationDisplayName property for each disk.

WHSInfoClass info = new WHSInfoClass();

foreach (IDiskInfo2 iDisk in info.GetDiskInfo())
	iDisk.LocationDisplayName = "My new location (SATA)";

That’s it. Your disks will now all show “My new location (SATA)” under the Location column on the Server Storage tab.




If you want to ditch your custom location, just set LocationDisplayName to string.Empty and the Windows Home Server console will go back to using the default value for Location for that disk.

WHSInfoClass info = new WHSInfoClass();

foreach (IDiskInfo2 iDisk in info.GetDiskInfo())
	iDisk.LocationDisplayName = string.Empty;

This is great functionality if you’re an OEM building a custom Windows Home Server that has clearly labelled drive bays. Instead of “SCSI”, you can now set “Internal Drive 0 (SATA)” to make it easier for your users to identify which disk to pull.

The only question here is who’s going to volunteer to develop the first Add-In that lets us write custom values to LocationDisplayName?


End-User License Agreements for Add-Ins

The Windows Home Server developer guidelines state that the .msi package for an Add-In should be silent; a user shouldn’t be prompted for any information, and the install should complete without any input whatsoever. That presents a problem when a software developer wants to include a license agreement with their Add-In.

In Power Pack 2, Add-In developers now have the ability to include a custom EULA with their .msi file.

The process couldn’t be simpler, really; all you need to do is include an .rtf file with the same name as your Add-In .msi in the \Software\Add-Ins folder on the server, and the contents of that .rtf will be displayed as a license agreement during the Add-In install process.

If your Add-In is packaged as MyAddIn., for example, you’d name your license file MyAddIn. so that the WHS Console could display it.





I’m still debating how best to deploy a license file with an Add-In; normally, I just offer the basic .msi file for download. Users can then just drop the file directly into the \Software\Add-Ins folder, and install it. So packaging a license file with the Add-In is probably going to require pushing both the .rtf and .msi into an archive of some kind (.zip, .rar, etc.) and asking users to decompress the archive manually. Not a clean solution, in my opinion.

Still, having the option to display a EULA is invaluable when you’re talking about a commercial Add-In.


Carpe SDK

There you have it, some shiny new things in Power Pack 2 for us developers to play with. Who says the media guys are the only ones who have any fun?

posted on Tuesday, March 24, 2009 4:44 PM | Filed Under [ Windows Home Server Development ]


Site Sections

Recent Posts


Post Categories

WHS Add-In Tutorial

WHS Blogs

WHS Development