tentacleBlog

We Got Served Reader Awards 2008 Results

WGS have posted the results of their Reader Awards 2008 competition.

Windows Home Server Disk Management was beaten out this year by Kentdome Technologies’ Grid Junction Add-In. Of course, I can’t complain; I use Grid Junction on a number of Windows Home Servers myself!

So, congratulations to Alexander on winning this year! We’ll have to be content with second place.

Installing and starting a Windows Service using WiX

Using WiX to install and start a Windows Service as part of your Add-In install is fairly easy. The only thing you really have to watch out for is the KeyPath value for your service executable; it has to be set to yes, while all other file KeyPaths must be set to no.

Make sure you also use your own GUID values for UpgradeCode and Component ID values.

This code works with the latest WiX 3.0 weekly build.

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product
    Name="Windows Home Server Disk Management Add-In"
    Id="*"
    UpgradeCode="{EB6B8302-C06E-4bec-ADAC-932C68A3A98D}"
    Manufacturer="Sam Wood - Tentacle Software"
    Version="1.1.0.0"
    Language="1033">
    <Package
      Manufacturer="Sam Wood - Tentacle Software"
      InstallerVersion="200"
      Languages="1033"
      Compressed="yes" />

    <Media Id="1" Cabinet="WHSDiskManagement.1.1.0.0.cab" EmbedCab="yes" />

    <Property Id="WHSLogo">1</Property>

    <Condition Message="[ProductName] requires Windows Home Server. For more information, please refer to the User Guide.">VersionNT = 502</Condition>

    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder" Name="PFiles">
        <Directory Id="WHS" Name="Windows Home Server">
          <Component Id="HomeServerConsoleTab.DiskMgt" Guid="{908B7199-DE2A-4dc6-A8D0-27A5AE444FEA}">
            <File Id="HomeServerConsoleTab.DiskMgt.dll" Name="HomeServerConsoleTab.DiskMgt.dll" Source="..\HomeServerConsoleTab.DiskMgt\bin\Release\HomeServerConsoleTab.DiskMgt.dll" Vital="yes" KeyPath="no" DiskId="1"/>
            <File Id="DiskMgt.Common.dll" Name="DiskMgt.Common.dll" Source="..\DiskMgt.Remotable\bin\Release\DiskMgt.Common.dll" Vital="yes" KeyPath="no" DiskId="1"/>
            <File Id="DiskMgt.Service.exe" Name="DiskMgt.Service.exe" Source="..\DiskMgt.Service\bin\Release\DiskMgt.Service.exe" Vital="yes" KeyPath="yes" DiskId="1"/>
            <ServiceInstall
              Id="ServiceInstaller"
              Type="ownProcess"
              Vital="yes"
              Name="DiskManagement"
              DisplayName="Windows Home Server Disk Management"
              Description="Monitoring and management service for Windows Home Server Disk Management Add-In"
              Start="auto"
              Account="LocalSystem" 
              ErrorControl="ignore" 
              Interactive="no"
              >
              <ServiceDependency Id="QSM"/>
              <ServiceDependency Id="pdl"/>
              <ServiceDependency Id="WHSTransportService"/>
            </ServiceInstall>
            <ServiceControl Id="StartService" Start="install" Stop="both" Remove="uninstall" Name="DiskManagement" Wait="yes" />
		  </Component>
	    </Directory>
	  </Directory>
	</Directory>

	<Feature Id="ProductFeature" Title="WHSDiskManagement" Level="1">
      <ComponentRef Id="HomeServerConsoleTab.DiskMgt" />
	</Feature>
  </Product>
</Wix>

ServiceDependency values are the real names for the services your code depends on. You can find the Service Name by opening services.msc and checking the properties for the specific service.

The ServiceControl node allows you to start and stop services during install and uninstall.

In the example above, I’m controlling a service called DiskManagement (the service I’m installing in the parent ServiceInstall node, but it could be any service). The service is started after the MSI package has been installed, stopped (if it’s started, to allow me to overwrite or delete the service’s files) at the beginning of both install and uninstall operations, and removed at the end of an uninstall operation.

The Service Control Id value is just an identifier that you can use to refer to this specific ServiceControl node in other places in the XML.

If you want to use extended character sets (for localization into different languages, usually) in the various display and description fields, you’ll need to set the xml encoding value and Product Codepage appropriately. I’ve also set the Product Language and Package Languages to German in this example:

<?xml version="1.0" encoding="Windows-1252"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product
    Name="Windows Home Server Datenträger-Verwaltung"
    Id="*"
    UpgradeCode="{EB6B8302-C06E-4bec-ADAC-932C68A3A98D}"
    Codepage="1252"
    Manufacturer="Sam Wood - Tentacle Software"
    Version="1.1.0.0"
    Language="1031">
    <Package
      Manufacturer="Sam Wood - Tentacle Software"
      InstallerVersion="200"
      Languages="1031"
      Compressed="yes" />

There’s some good documentation on the rest of the options (ownProcess, Start type, Account etc.) in the WiX help files that get installed along with the WiX binaries. It’s not the most friendly set of technical docs I’ve seen, but it does give detailed descriptions of the individual configuration elements.

Testing SyntaxHighlighter

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">    
  <Product    
    Name="My First Add-In"   
    Id="*"   
    UpgradeCode="{1a7c55f0-ceed-11dd-ad8b-0800200c9a66}"   
    Manufacturer="Sam Wood - Tentacle Software"   
    Version="0.0.0.1"   
    Language="1033">    
    <Package    
      Manufacturer="Sam Wood - Tentacle Software"   
      InstallerVersion="200"   
      Languages="1033"   
      Compressed="yes" />     
</Wix>

Ok, I think I like this better. Easy to copy and paste, and it looks pretty slick now that I’ve got the pre-wrapping resolved. Not sure if I love the idea of javascript running through the page and updating styles post-load, but I think the end result is worth it.

What I’m not going to like is having to go back through all the tutorials and update the code snippets!

Let me know your opinion.

Unplanned downtime

Our domain registrar has had major issues with their nameservers over the last 24 hours. This has meant that our web site has been inaccessible for a long period of time.

The provider in question has informed us that the issue has been resolved, but it may take up to 24 hours for DNS replication before the site becomes accessible globally once more.

Thanks for your patience.

"Hello World" Windows Home Server Add-In: Part 5

This is the fifth part in a series of tutorials aimed at guiding novice developers though building a "Hello World" Windows Home Server Add-In, using only freely-available tools (including Visual Studio Express).

In Part 5, the last part of our tutorial, we'll wrap our Add-In as part of an MSI package so we can deploy it using the Windows Home Server Console.

For this tutorial, we're building a Windows Home Server Add-In that detects changes to Shared Folder permissions. You can access the other parts of the tutorial, or download the code I'm using in the screenshots, using the links below.

• Part 1: Installing and configuring your development environment
• Part 2: Designing a GUI and initial deployment test
• Part 3: Responding to Windows Home Server Notifications (code)
• Part 4: Using FancyListView and comparing permissions (code)
• Part 5: Building an installer package using WiX (code)

Note: The code samples below don't copy and paste very well directly into Visual Studio. If you don't want to type them out by hand, copy the sample into WordPad, and then copy from WordPad into Visual Studio.

Part 1: Add a new XML file

Creating an installer package for our Add-In is relatively straightforward. We just need to create a new XML file as part of our solution that contains the metadata needed by WiX to build the correct MSI file.

Right-click our project and add a New Item. Choose XML File and name the file installer.wxs.

You'll be presented with a new, blank, XML file. The easiest way to build WiX files is to reuse an existing one, so we'll use the same XML data I use for WHS Disk Management.

You'll want to change the Manufacturer information, of course. Also, where you see GUIDs (UpgradeCode and Component Guid), you'll want to generate your own unique values (use the same tool as last time: http://www.famkruithof.net/uuid/uuidgen).

Since we're only adding a single file, the XML isn't too complex. Note the Component Source directory path; you'll want to make sure this is correct on your development machine (you're probably not logged in as Administrator, for example).

The other critical section is the Property identified as WHSLogo. The Windows Home Server Console checks this value to determine if your MSI file is a valid WHS Add-In, so make sure you set it to 1.

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">

  <Product

    Name="My First Add-In"

    Id="*"

    UpgradeCode="{1a7c55f0-ceed-11dd-ad8b-0800200c9a66}"

    Manufacturer="Sam Wood - Tentacle Software"

    Version="0.0.0.1"

    Language="1033">

    <Package

      Manufacturer="Sam Wood - Tentacle Software"

      InstallerVersion="200"

      Languages="1033"

      Compressed="yes" />

    <Media Id="1" Cabinet="MyFirstAddIn.0.0.0.1.cab" EmbedCab="yes" />

    <Property Id="WHSLogo">1</Property>

    <Condition Message="[ProductName] requires Windows Home Server. For more information, please refer to the User Guide.">VersionNT = 502</Condition>

    <Directory 

      Id="TARGETDIR" Name="SourceDir">

      <Directory Id="ProgramFilesFolder" Name="PFiles">

        <Directory Id="WHS" Name="Windows Home Server">

          <Component 

            Id="HomeServerConsoleTab.My_First_Add_In" 

            Guid="{47d62350-ceed-11dd-ad8b-0800200c9a66}">

            <File 

              Id="HomeServerConsoleTab.My_First_Add_In.dll" 

              Name="HomeServerConsoleTab.My_First_Add_In.dll" 

              Source="C:\Documents and Settings\Administrator\My Documents\Visual Studio 2008\Projects\My First Add-In\My First Add-In\bin\Release\HomeServerConsoleTab.My_First_Add_In.dll" 

              Vital="yes" 

              KeyPath="yes" 

              DiskId="1"/>

          </Component>

        </Directory>

      </Directory>

    </Directory>

    <Feature Id="ProductFeature" Title="MyFirstAddIn" Level="1">

      <ComponentRef Id="HomeServerConsoleTab.My_First_Add_In" />

    </Feature>

  </Product>

</Wix>

Part 2: Create a batch file

If you're lucky enough to own a copy of Visual Studio (that isn't the Express edition), WiX will integrate with your development environment. That means you can build MSI packages from within Visual Studio as part of your normal project build process.

Because we're using Visual Studio Express, we don't get that integration. We'll have to use the WiX command-line tools to get the job done.

To make things easier, we'll create a batch file so that we don't have to type the same commands over and over (trust me, you'll be doing a lot of MSI building if you're a WHS developer!). Right-click the project and add a New Item. This time, we'll create a text file.

Call it installer.bat. 

Visual Studio creates a text file with an encoding that doesn't quite work. That's OK, it just means that the first line in our batch file will error out; we'll make sure our first line doesn't really matter.

Add the following text to our batch file and save it. Again, note our paths pointing to the \bin\release folder of our project; make sure they match the paths on your development machine. The quotes are important too, don't forget them!

pause

"C:\Program Files\Windows Installer XML v3\bin\candle" -out "C:\Documents and Settings\Administrator\My Documents\Visual Studio 2008\Projects\My First Add-In\My First Add-In\bin\Release\install.wixobj" "C:\Documents and Settings\Administrator\My Documents\Visual Studio 2008\Projects\My First Add-In\My First Add-In\installer.wxs"

"C:\Program Files\Windows Installer XML v3\bin\light" "C:\Documents and Settings\Administrator\My Documents\Visual Studio 2008\Projects\My First Add-In\My First Add-In\bin\Release\install.wixobj" -out "C:\Documents and Settings\Administrator\My Documents\Visual Studio 2008\Projects\My First Add-In\My First Add-In\bin\Release\MyFirstAddIn.0.0.0.1.msi"

Once you're done, save the file. Navigate to your project's directory and run the installer.bat file. You should see candle and light building the MSI package.

When the command prompt disappears, check the \bin\release folder of your project for the new MSI package.

If it's not there, you might be missing some errors that candle or light are throwing; you can add another pause at the end of the batch file to stop the command prompt closing until you press a key.

Step 3: Installing the Add-In

You'll want to clean up our test Add-In file from the previous tutorials so that we can verify our installer is actually installing files. Delete HomeServerConsoleTab.My_First_Add_In.dll from C:\Program Files\Windows Home Server\ on your server.

Copy the MSI file to \Software\Add-Ins on your server.

Now, open the WHS Console, click Settings and change to the Add-Ins tab. Under Available Add-Ins, our Add-In should be listed. Let's install it now.

When the installation is complete, WHS will prompt you to restart the console. Log in again, and, through the magic of television, our Add-In has been installed and is working correctly!

Try uninstalling the Add-In through Settings, and verify that our MSI package can be uninstalled as expected.

Well, that's it for this tutorial. You've created and deployed a Windows Home Server Add-In completely from scratch, and it actually works! Congratulations.