Q: Is there any way to more rapidly test my add-in than copying it over to my WHS and restarting the console every single time I want to view a minor change?

A: There are a few different ways (some of which I'll be covering in later tips) to test your add-in without manually copying it over to the server.

UserControl Test Container

If you are doing your development in VB.NET (2005 or 2008), are using UserControls (such as from the add-in template), and hit the F5 key to debug your work... then you've likely seen the UserControl TestContainer which is a simple application that lets you quickly test out a user control on a form.

It works great... but is limited, especially considering it's not automatically wired up for C# projects, something that is tricky to do with C# Express.

Stand-alone application

Another quick and easy option that works equally well with any language is to add a new Windows Forms project to your solution that your add-in.

This method enabled you to add your user controls to a form or two that you control and test them out in a similar manor to what the UserControl Test Container gives you.

This too works great... but there is a better way.

WHS Test Loader

My preference has been for a tool I created called WHS Test Loader tool (previously discussed) which uses similar rules (from what I can discern) to the Home Server Console for loading an add-in and displays both it and the settings to the screen.

While it doesn't give you everything that the real console does, it at least lets you test your add-in a bit on your own PC in more ways than just visually.

Overview

In addition to providing a couple of tabs which hold the actual main and settings tab controls, those tabs can also be accessed by clicking on one of the GroupBoxes which give a very loose idea of what your tab's buttons will look like in the Console.

If you are planning on using some form of localization in your add-in, one of the most useful features to you will be the CurrentUICulture ListBox which lets you change the culture of the application's UI thread. Using this, you can easily test your add-in in English, German, Croatian or any other language or culture you want, it's just up to you to define the languages that you'll support.

The Additional Tools tab is intended to be a home for other general troubleshooting and testing bits... for now it simply displays the contents of the CommonImages class.

Another specialized feature offered by the Test Loader is a custom class that implements the IConsoleServices interface, an instance of which is passed into the constructor of your tab objects enabling you to still be able to call OpenSettings() and OpenUrl() without additional changes to your code to check if it is running in a test environment.

Usage

Start by downloading a copy of this tool to the same directory where you keep the files from your Home Server (due to all of the assemblies that it references).

Once there you can either launch it manually and use the Load Assembly button to select your assembly... or have Visual Studio launch it for you.

In order to configure Visual Studio...

1. Open your project in your non-Express version Visual Studio (Express specific instructions can be found in the last section)

2. Right click on your project in Solution Explorer and select Properties

3. Select the Debug tab

4. Change the start action to 'Start external program' and set the specified path to the location of WhsTestLoader.exe

5. Set the 'Command line arguments' option to the name of your assembly (available under the Application tab) with the trailing .dll

When all said and done you should end up with something that looks like this:

Once properly setup, when you next hit F5 (or what ever other method you use to start debugging) the Test Loader will launch with your tab inside, giving you a quick and easy method to test out some of the functionality of your add-in.

For curious readers, the C# source code for this application is available.

Sorry VB lovers, this app is C# only... but that doesn't mean you can't use the pre-built version to load and test add-ins written in the .NET language of your choice.

Administrator

A number of the controls and other less than documented features of the Home Server code that we can use requires elevated (administrative) permission... something that we as good programmers shouldn't be running as by default.

That being said, unfortunately in order to fully test an add-in it is often necessary to run the Test Loader as Administrator, the easiest way to achieve is simply to run your instance of Visual Studio as Administrator (when running Vista) so that each time you attempt to debug, you are not greeted with a UAC prompt.

Express Editions

The Express Editions of Visual Studio (both 2005 and 2008) are purposely limited so as to encourage you to eventually by the higher (and pricey) versions of Visual Studio... the little secret is that most of those limitations are implemented in the user interface... which means that will a little knowledge of how the back-end files works, you can take advantage of a few less than well known features.

One of the wonderful things about the Express Editions is that they use the exact same project and solution file format as the higher versions, enabling you to easily move code back and forth when needed.

Another advantage of this is that the Express Editions will act on settings in a project file, even if it is incapable of setting it and such is the case with setting the Start Action.

In order to make your project in Express launch the Test Loader, you'll need to break out your favorite text editor (ie notepad) and create a new file with these contents:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <StartAction>Program</StartAction>
    <StartProgram>E:\WHS Dev\WHS - Server\WhsTestLoader.exe</StartProgram>
    <StartWorkingDirectory>
    </StartWorkingDirectory>
    <StartArguments>HomeServerConsoleTab.Home_Server_Add_In1.dll</StartArguments>
  </PropertyGroup>
</Project>

You will likely have to change the StartProgram tag to specify the path to where you put WhsTestLoader.exe, as well as StartArguments to reflect your assembly name.

Next, save this file in the same directory as your project's project file (.csproj or .vbproj) and name it depending on your language:

ProjectFileName.vbproj.user

or

ProjectFileName.csproj.user

where ProjectFileName is the name of your project file.

Because the text editor you are using probably doesn't default to using the .user extension, you'll need to wrap the entire filename in double quotes to force it to use that name, instead of letting it append it's own default extension to the end.

Please note that the file name must be exact, so if your project's name is "Home Server Add-In1.vbproj", then your new file must be named "Home Server Add-In1.vbproj.user".

Once you've created this file, load your project up in Express and hit F5 to begin debugging to launch the Test Loader with your add-in in it much like the folks with the expensive versions of Visual Studio.

Note: The information in this post is based on undocumented and at times deduced information on Windows Home Server and is not officially supported or endorsed by Microsoft and could very easily be wrong or subject to change in future, so please take it and everything else said on this blog with a grain of salt and use with caution.

Read the complete post at http://ihatelinux.blogspot.com/2007/11/whs-developer-tip-7-testing-without.html