Building Add-ins

  • Article

How do you build Add-ins? Awfully hard for me to say. That's kind of like asking how you should build a Windows application. Oh, wait, it's exactly like asking how you should build a Windows application.

However, I can provide some general guidelines for developing Windows Home Server Add-ins:

  • Call them Add-ins. That's what we call them.
  • If your code currently installs and runs on Windows Server 2003 it will probably install and run on Widows Home Server.
  • If your code currently installs and runs on Windows XP or Windows Vista, but does NOT currently install and run on Windows Server 2003 you'll probably have 3 general areas to work on:
    • Your installer. Check if you are running on Windows Home Server version information using GetVersionEx() and looking for VER_SUITE_WH_SERVER. Also understand the Add-in manager and to craft MSI file that work with it.
    • Your code as a service. There's no desktop session you can run under on Windows Home Server. Your long running code must be installed as service using the standard Windows service APIs (or it can run under the context of IIS of course).
    • Testing against Windows Home Server. There are differences in the Windows API between Windows XP, Windows Vista, and Windows Server 2003. They are relatively minor, but they do crop up and the best way to identify these is to make sure you do a full test pass.
  • If you are developing something new, don't get hung up on the fact that Windows Home Server is still in beta and our SDK might change slightly before we ship. Just get started solving the really hard problems on your dev machine. All the really important APIs and services are all there (repeat to yourself "Under the covers it's practically W2K3").
  • The Home Server Console is designed to be an infrequently used application. It is intended to be used by one individual in the household (whoever the sucker was who signed up for helping everyone else) for infrequent configuration tasks. We call this person Jeff (we used to call him Peter but for reasons I will not get into here we had to change...don't ask).  It would be a mistake to implement UI in the admin console that you expect Jeff's family members to access.  Instead, build client-side UI for them.
  • Be seriously thoughtful about the implications your design and code can have on security. We have worked very hard to ensure that Windows Home Server is secure by default. You need to do the same thing.
  • Use the Windows Home Server forums to share your experiences and to get assistance.

What should you build? I can't really answer that directly. But I can tell you to think generally about it using the generic definition of home server:

"A home server is an always available smart node on the home network dedicated to providing services to other nodes on the home network and the Internet."

Relative to this, Windows Home Server provides you with:

  • A stable platform for services in the house that need to be "always available".
  • A built-in set of enterprise-class infrastructure services such as IIS.
  • A rich, well documented, and widely used API (the Windows API) for building Add-ins.
  • A broad ecosystem of already existing tools and technologies that can help you build Add-ins (e.g. everything ranging from PowerShell, to Visual Studio Express, to Ruby on Rails).

Beyond that, I'm confident the community will have no trouble suggesting actual problems to solve and solutions to create. In fact over on https://www.onemanshouting.com/, Rick has a nice post on this. Dan Fernandez blogged about it a while ago, and I'm sure he'll post something new now that the SDK is out. And if you are still out of ideas, check out the suggestions section of the Windows Home Server forum.

So what are you waiting for? Go bang out some code already!

-cek