This is great for constrained TFS build environments, and although not supported in any way, this does allow you to edit and build simple Silverlight 4 apps created first for Silverlight 3, using Visual Studio 2008.

Background

On the Silverlight Toolkit team, we have a need to always have a previous version branch, and a new version, building together in a daily TFS Build. We do this by having the Silverlight 3 and Silverlight 4 SDKs, reference assemblies, and other resources checked into the source enlistment.

Caveats

This post is not intended for the general Silverlight developer: it is designed for build engineers and continuous integration fans that need to build both versions. Since the adoption rate of new Silverlight versions is typically very quick, the need to build previous versions diminishes very quickly in my opinion.

Important: this will be using the .NET 3.5 C# compiler, and not the C# 4 compiler. This means that you will not have the ability to build apps that use the new dynamic language feature.

Important note 2: this assumes you are starting with a Silverlight 3 class library or app, not one that you created in Visual Studio 2010. The project file formats in 2010 are updated to use MSBuild 4 and a few other differences, so this scenario (basically building SL3 project formats against the SL4 runtime) is not for everyone.

Important note 3: Visual Studio 2010 supports multi-targeting Silverlight, so you can create projects in 2010 that are 3 or 4 much easier – no need for any of these hacks if your build environment already has .NET 4.

This is based on a previous post about building Silverlight 2 and 3 together.

This method does not require a build machine to have Silverlight installed at all, nor any of its SDKs.

Preparing your source enlistment

You want to copy the various build assets for both Silverlight 3 and Silverlight 4 into the tree, in a folder such as ExternalTools\Silverlight\v3 and v4. Repeat these steps for each version of Silverlight (v3.0, v4.0 directories) you need to build:

• Create a directory to store the MsBuild assets for Silverlight, and copy in the files from %programfiles%MSBuild\Microsoft\Silverlight\v3.0.
• Copy the “Reference Assemblies” directory from %programfiles%\Microsoft SDKs\Silverlight\v3.0\ into the tools directory.
• Copy the “Libraries” directory from %programfiles%\Microsoft SDKs\Silverlight\v3.0\ into the directory.

You can then use relative paths in your projects or custom build targets to get things rolling.

Customizing the <Import /> element in your projects

Within your source enlistment, you must then update all Silverlight project files to instead reference the relative-path building scripts instead of those installed on the machine.

Even when building in Visual Studio 2008, the proper version will build.

On the Toolkit team, all VB and C# source projects within the enlistment reference a relative path, typically something like ..\..\Silverlight.CSharp.targets, instead of the standard Silverlight CSharp targets from the Silverlight MSBuild scripts.

Inside this relative path, it defines the properties. For Silverlight 3:

<Project
  ToolsVersion="3.5"
  DefaultTargets="Build"
  xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>
    <!-- Define the ExternalTools property first -->
    <SilverlightBuildResources>$(ExternalTools)\Silverlight\v3.0\</SilverlightBuildResources>

    <TargetFrameworkDirectory>$(SilverlightBuildResources)Reference Assemblies\</TargetFrameworkDirectory>
    <TargetFrameworkSDKDirectory>$(SilverlightBuildResources)Libraries\Client\</TargetFrameworkSDKDirectory>
    <SilverlightRuntimeVersion>3.0.40217.0</SilverlightRuntimeVersion>
  </PropertyGroup>
  <Import Project="$(SilverlightBuildResources)Microsoft.Silverlight.CSharp.targets"/>
</Project>

And for Silverlight 4:

<Project
  ToolsVersion="3.5"
  DefaultTargets="Build"
  xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>
    <!-- Define the ExternalTools property first -->
    <SilverlightBuildResources>$(ExternalTools)\Silverlight\v4.0\</SilverlightBuildResources>

    <TargetFrameworkDirectory>$(SilverlightBuildResources)Reference Assemblies\</TargetFrameworkDirectory>
    <TargetFrameworkSDKDirectory>$(SilverlightBuildResources)Libraries\Client\</TargetFrameworkSDKDirectory>
    <SilverlightRuntimeVersion>4.0</SilverlightRuntimeVersion>
  </PropertyGroup>
  <Import Project="$(SilverlightBuildResources)Microsoft.Silverlight.CSharp.targets"/>
</Project>

Note that we are only providing the major version here, this prevents having to update with each new build of Silverlight 4.

Adding Silverlight Toolkit support

To build apps that use the Silverlight Toolkit in a similar manner, just copy the Silverlight Toolkit binaries into the same client libraries folder of the SDK.

WCF RIA Services Note

There’s a hard-coded import statement that will import a single version of the WCF RIA Services if present on the machine.

At the bottom of the Silverlight 4 file Microsoft.Silverlight.Common.targets, you will see this line:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\Silverlight\v4.0\Microsoft.Ria.Client.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\Silverlight\v4.0\Microsoft.Ria.Client.targets')"/>

You may want to comment out or remove this line if this impacts your multi-version builds in any way.

Hope this helps.

VSIX files can contain a digital signature

Which extension would you rather install? Here’s one without a digital signature:

And one with:

Download My SignExtension Tool

This is a simple .NET 4 app that allows you to select your .Vsix file, your .Pfx file, enter a password, and sign away.

SignExtension.zip (30 KB, contains the app only. App is signed.)
SignExtension.Source.zip (27 KB, contains the Visual Studio 2010 project source for .NET 4 only)

How to manually sign an extension

The new .Vsix files are really glorified zip files, and the extensions manager is able to identify when such files have a verified digital signature. However, there isn’t a Subject Interface Package (SIP) for VSIX, so the traditional SignTool.exe program cannot sign extension packages.

Instead, you need to use the System.IO.Packaging namespace and the PackageDigitalSignatureManager type to sign, using a X509Certificate2 type.

It took some trial and error, plus discussion searching, to find the best common practice for this. Here’s some of that key code:

private static void SignAllParts(Package package, string pfx, string password, string timestamp)
        {
            var signatureManager = new PackageDigitalSignatureManager(package);
            signatureManager.CertificateOption = CertificateEmbeddingOption.InSignaturePart;

            List<Uri> toSign = new List<Uri>();
            foreach (PackagePart packagePart in package.GetParts())
            {
                toSign.Add(packagePart.Uri);
            }

            toSign.Add(PackUriHelper.GetRelationshipPartUri(signatureManager.SignatureOrigin));
            toSign.Add(signatureManager.SignatureOrigin);
            toSign.Add(PackUriHelper.GetRelationshipPartUri(new Uri("/", UriKind.RelativeOrAbsolute)));

            try
            {
                signatureManager.Sign(toSign, new System.Security.Cryptography.X509Certificates.X509Certificate2(pfx, password));
            }
            catch (System.Security.Cryptography.CryptographicException ex)
            {
                System.Windows.Forms.MessageBox.Show("Signing could not be completed: " + ex.Message, "Signing Failure");
            }
        }

Hope this helps.

I recently jumped in and acquired an Authenticode code signing certificate & key pair. It’s great being able to sign my .NET executables, installers, and even Visual Studio 2010 extensions.

I’m documenting my efforts here in the hope that others would be able to follow the relatively straightforward process – there’s not much magic other than learning to export and work with the certificate mechanisms inside Windows. But I know a lot of devs see it as a black magic art, and really it’s just about time, money, and some quick learning.

Which dialog would you click ‘Yes’ on?

Windows 7 is leaps and bounds ahead of Vista in terms of usability. The improved User Account Control experience is nice. I think that a lot of people are finally becoming more wary of unsigned software, especially installers.

With the net full of stories of mirror servers becoming compromised, or people blinding clicking yes on many dialogs, the assurance of the dialog without the scary orange warning banner is the one I think every software developer would like to offer their customers. It’s the professional thing to do.

So here we are, from start (no cert) to finish (signing a .NET app). It only took about two days to go through the identity verification process, but the time was well worth it – and the rest is easy given the nice signing tools in Windows and Visual Studio.

We’ll be getting a certificate & private key through a trusted root certificate authority (CA) provider, not test signing or self-signing. If you’ve ever purchased an SSL certificate for your web servers, similar process.

For a list of current program members, see this download on the Microsoft site – there are hundreds of businesses and governments in the program.

Some corporate IT departments will have their own internal CA, so although those companies can sign apps for internal use, using them on machines without that CA cert installed will yield the un-trusted publisher dialog.

What is Authenticode?

Authenticode is the name for the code signing system on Windows. There are many tools from Microsoft that are core to code signing and ship in the Windows SDK.

Code signing certificates have an expiration date, but as long as a timestamp server is used when signing, signed apps can still be used and verified. Certificates can also be revoked if ever compromised.

For good measure, here’s a short Wikipedia page on code signing, and the MSDN document “Introduction to Code Signing”.

What code signing is not

Signing is only a way of proving that some person or company is who they say they are. It doesn’t tell you whether there’s a nice person, or in any way validate functionality of an app.

Also, .NET projects have a “Signing” tab, but this is actually a feature called Strong Naming, and is different. Most commercial software products using .NET will be both strong named, plus be code signed.

What all can you use your $99/year key for?

• Signing Windows executables
• .NET programs, class libraries, ClickOnce apps
• .MSI installer files
• Adobe AIR apps
• Java JARs
• Microsoft Office/VBA macros
• Mozilla objects and extensions
• Signing Visual Studio extension packages (.vsix files), although SignTool doesn’t directly support this (no SIP module)

Note that only Verisign offers code signing certificates for Windows device drivers through a special program for kernel-mode code signing.

How does Microsoft do code signing?

Obviously the Microsoft corporate keys are extremely secure and private. All signing is performed through a set of intricate systems that accept builds, check conditions, scan for viruses, and who knows what else… and eventually provide the signed binaries.

It’s pretty much a black box to us as engineers, but it works for hundreds of thousands of files.

As a dev, I’ve had more than my share of wild Friday nights trying to get code strong named and signed: there’s a big process and it revolves around a lot of people, smart cards, and it eventually works out.

Step-by-step guide to purchasing a certificate

Here’s my experience with getting a certificate. Different certification companies may have different processes, but in general you can be sure that you will need to do a lot to provide proof and authenticity of your name/company.

You can purchase a personal certificate (independent developer, professional geek) quicker than a corporate certificate given the different proof requirements.

Since the name/company name is what will be shown in the publisher field, you obviously wouldn’t want to get a personal certificate for company use. Also, be aware that the address you provide to a signing company will be embedded inside the certificate.

I purchased my code signing cert through K Software, which is an official reseller of Comodo certificates, a popular Level 2 CA whose certificates are part of the root CA program on computers everywhere. The certificate costs $99 per year. I’ve heard of other companies sometimes offering specials as low as $65 a year, and others such as Verisign asking $499 a year.

Since there is some pain in the process (producing copious amounts of evidence) and waiting for that to be validated, you may want to consider purchasing a multi-year certificate and skip having to renew yearly.

You must use Windows and either Internet Explorer or Firefox to make the initial request. After the entire process is complete and the certificate is issued (days later), you will need to use the same computer and browser to complete the process. You will then export the certificate and private key to a file so you can store it safely somewhere.

What proof will be required

This is a partial list, the authentication process may require other documents. Most verification can be done through fax, mail, or even email.

If you’ve ever purchased an SSL certificate, it’s almost the same exact process.

• Your own domain name:

• The domain’s WHOIS records must match the information you provide in your order.
• If you use Private Registration services, you’ll need proof from the private registration company that you own the domain and your address matches. This can be a pain.

• Articles of Incorporation
• Business License
• Other documentation such as DUNS details

• Driver’s license or passport
• Recent utility statements with matching data
• Phone statement with matching information, name, and phone number where final phone verification will be performed

This information will be asked for after you order and pay for the service. It is performed by the CA (Comodo in my case), not by the company or reseller you buy the service from.

For the remainder of this section, everything will be specific to Comodo. I found them helpful, quick and responsive, and professional, so I would definitely recommend their service. It is a great value when purchased through a reseller.

Step 1: Register with the CA to track your validation tickets and receive support

You’ll need to do this with an email address at your domain name. You register with the same email you’ll use in the next step.

If you don’t usually receive mail at your domain, you should be able to easily setup mail forwarding to your normal mail address. On a Windows server, SmarterMail Free sets up in minutes and is great for this.

Simply create an account at Comodo Support for this: https://support.comodo.com/index.php?_m=core&_a=register

Step 2: Submit basic data and purchase

Start at the K Software site, which is a reseller of Comodo’s: https://secure.ksoftware.net/code_signing.html

Current prices are $99 US for one year, $198 for 2 years, and so on.

After navigating to the page, click Buy Now. Internet Explorer will pop up a message that the site is attempting to perform a digital certificate operation. Click Yes.

On the order form page, you will submit your details, including address, email, etc. The email address needs to be an email address on your domain name that can be verified, not a Hotmail or Google Mail address. Note that this information will be embedded inside the final issued certificate.

Important values at the end of the page:

• CSP should be Microsoft Enhanced Cryptographic Provider v1.0 (the default)
• Key size: 2048 is fine for most people
• Exportable: definitely – if you don’t check this, you can’t get a PKCS 12 (.pfx on Windows) file to use for signing, and would have to do all signing on that machine
• User protected: Leave this unchecked

After clicking Submit Order, you’ll go to a payment page. I used PayPal and was done in seconds.

Step Three: You’ll be contacted

At this point you’re done with the K Software order. You will be contacted via e-mail from Comodo, and they’ll step you through what verification they need at that time, and how to submit it.

In my case I had to go through several rounds of verification, including sending a recent phone bill.

I ran into some hiccups because the domain name I used for the e-mail address, though owned by me, is hard to prove: my WHOIS data all says ‘Domains By Proxy’, which is the provider of private registration services for GoDaddy. I had to find a way to provide proof that I own the domain.

The final verification step is when they eventually call your phone number. After that call, they’ll issue the certificate approval, and you’ll receive a final e-mail about 20 minutes later to go pick up the certs.

This step took me 1.5 business days including waiting time.

Step Four: Pick up your key

On the same computer you started the operation on, and same browser, click on the link provided in the e-mail Comodo sent when the key was ready.

On this page, you’ll again receive a notification about a certificate operation. That’s fine. At this point you now have the key stored in your browser certificate system.

Step Five: Export your key

This step is for Internet Explorer users. If you’re using Mozilla Firefox, here’s some other instructions.

In IE now, click Tools | Internet Options. Click on the Content tab, and then the Certificates button:

Within the Personal (first) tab of the Certificates dialog, click on the new certificate issued by UTN-USERFirst-Object (this is one of the many Comodo level 2 CAs in the Windows root CA program):

Then click ‘Export…’. In the Certificate Export Wizard, read the useless text and click Next.

Select the option ‘Yes’ for exporting the private key along with the certificate.

Next, you pick the file format. Only PFX/PKCS #12 should be available. I checked both ‘Include all certificates in the certification path if possible’ and ‘Export all extended properties’, though to be honest I haven’t a clue whether this is needed.

I wouldn’t recommend clicking the delete private key option, I like knowing that on this particular machine I can still re-export the cert as needed in the future.

Now, come up with a password to protect the file. You will need to use this password when using tools such as SignTool.exe, or setting up an automated code signing process of your own.

Finally, pick where you want your .PFX file stored.

Step Six: Protect your key

Although code signing certificates have a mechanism through the CA to revoke keys, you do not ever want to have to do this.

Take precautions. It is your duty to protect your key. Many people find ways to store this information through smart card or other physical security mechanisms.

As an individual, it’s pretty easy for me: Only I know the password, I have the file securely stored, and I don’t need to worry about sharing it with others.

Business entities and groups will have more trouble coming up with the appropriate processes and systems for this. Ideally some sort of automated system should be used to perform the code signing, with alternative authentication; providing the key file and a password is not the best method.

Import Wizard Note

To manually sign on another machine, you’ll want to double-click on the .pfx file. An import wizard will open up that will allow you to install the cert and private key on your machine.

For manual signing you typically select from your private certificate store on the machine, instead of using the .pfx file directly. For automated signing, you probably will use the .pfx.

How to sign your apps and libraries

Now the fun part. Armed with your new code signing certificate and private key, you’re ready to go SignTool.exe’ing.

SignTool is included with the Windows 6.0 and 7.0A SDKs, and you’ll have it in your path if you have Visual Studio 2008 or 2010 installed and are using the associated Visual Studio Command Prompt.

You can create scripts to sign quickly using command line parameters, or even write .NET apps using types in the System.Security.Cryptography.X509Certificates namespace.

It’s easiest to get started by manually signing, using the Digital Signature Wizard. From a Visual Studio 2008 Command Prompt, for instance, run:

signtool.exe signwizard

This will popup the wizard that will walk you through.

Select the file you want to sign:

The ‘Typical’ option will let you pick from the certificate store on your machine. You don’t actually select the previously-exported .PFX file when manually signing.

Here I click ‘Select from Store…’:

Which pops up a Windows dialog listing available code signing certificates.

Here I can verify the goods:

On the next wizard page, you can optionally offer more information here as appropriate.

The last optional, but highly recommended step, is to use the timestamp server provided by the CA. This is a service that authenticates when the data (your app) was signed.

This means that your app will continue to be valid, even after the certificate expires, as long as the cert is not revoked.

For Comodo, their timestamping server is: http://timestamp.comodoca.com/authenticode

Click Next and you’ll see the summary of what signing is to take place.

After clicking Finish, the dialog will go away, and pretty soon you should receive a success/failure message.

CodeSign.exe Parameters

You can also code sign in scripts and the command line using arguments. For instance, here’s a sample made-up signing argument list. You can specify any number of files to sign as the final arguments.

signtool.exe sign /f PathToKeysAndCert.Pfx /p “MySuperSecretPasswordToUseThePfxFile” /v /t http://timestamp.comodoca.com/authenticode “C:\MyFileToSign.exe”

For all the parameters, type ‘signtool sign /?’

That’s it!

You can use a variety of tools to check that the signing works fine, including just examining the file in the Windows explorer.

Authenticode-signed executables, MSIs and libraries will have a ‘Digital Signatures’ tab in the properties window (though not irregular file types, such as Adobe AIR files).

Here’s the .exe I signed:

And that’s it! Ship it!

Your customers will have that extra level of confidence when using your application. At some point, the more more professional software developers and software companies code sign, the more likely customers will be able to make proper security decisions about their computers… and the real benefit of the crisp user account control user interface comes to light.

Hope this helps. Let me know how your experiences with code signing go.

New infrastructure & test tools ship in the Silverlight Toolkit

There is a lot in the release that is joining publicly for the first time, based on some of the internal tools and utilities that we use in building and testing the Silverlight Toolkit, plus things we’d like to have as typical Silverlight developers.

These tools join in the Experimental quality band, and over the next few posts, I’ll dig into the details. This post is a literal walkthrough of how you could go about seeing all the utilities in the meantime.

One important thing to call out is that, as an initial release, there are definitely some rough edges: the test tools are centered around Microsoft Build (msbuild) integration, instead of Visual Studio integration; there’s no add-in or nice right-click project support to use these tools today.

We’ll be collecting feedback along the way and making changes in future releases. Until then, hopefully some of you will find the infrastructure useful, if only to peak behind the curtain. We’re also shipping the full source to these tools, you’ll find an Infrastructure.zip file inside the toolkit install folder.

What we’ll do in this walkthrough

This walkthrough uses Silverlight 4, though the instructions are virtually identical if you’re using Silverlight 3.

• Install the Silverlight Toolkit
• Create a new Silverlight class library with a simple business object
• Add a Silverlight Unit Test Application using the new templates found in the Silverlight Toolkit
• Run the tests in Visual Studio
• Run the tests from the command line in various browsers
• Collect block-level code coverage information for the build

This is screen-shot heavy, as future posts will dig into the details. I appreciate your patience!

Requirements:

• Latest Silverlight Toolkit
• For test automation:

• MSBuild on the machine

• Visual Studio 2010 Beta 2 Ultimate

Installing the tools

When you install either Silverlight Toolkit drop from November, you’ll see that there’s a new feature listed in the setup: the Tools & Templates feature. It’s selected by default, and adds Visual Studio templates, installs the tools, and prepares the tools if your machine has the proper dependencies on it.

Create a Silverlight Class Library

Open Visual Studio 2010 Beta 2, after installing the toolkit. Create a new Silverlight Class Library project, we’ll store a simple business object in it.

Whichever flavor of Silverlight you use, remember to use the same flavor while creating future projects in the same solution!

Create a new Person.cs type, with a few properties and a method. Here’s the source:

using System;

namespace MyApplication
{
    public class Person
    {
        public string First { get; set; }
        public string Last { get; set; }

        public string FullName { get { return First + " " + Last; } }

        public bool MightBe(string substring)
        {
            return FullName.Contains(substring);
        }
    }
}

Add a Silverlight Unit Test Application

Right-click on the solution in the Solution Explorer and select Add New Project. Under the Visual C# (and also Visual Basic) languages node, select the Silverlight subgroup. You’ll see a Silverlight Unit Test Application project template.

You now have two projects:

Next up, we want to add a reference to the class library, so that the unit tests can access the library. Right-click on the new test project and then select the Add Reference option. Under the Project tab, choose the class library you created earlier.

Now, let’s add some unit tests. Clear out the content in the created Tests.cs file and drop this in:

using Microsoft.VisualStudio.TestTools.UnitTesting;
using MyApplication;

namespace PersonTestProject {
    [TestClass]
    public class Tests
    {
        [TestMethod]
        public void TestCtor()
        {
            Person p = new Person();
        }

        [TestMethod]
        public void TestSetName()
        {
            Person p = new Person { First = "Scott", Last = "Guthrie" };
            Assert.AreNotEqual(p.First, p.Last);
        }

        [TestMethod]
        public void TestGetFullName()
        {
            Person p = new Person { First = "Steve", Last = "Ballmer" };
            StringAssert.Equals("Steve Ballmer", p.FullName);
        }
    }
}

The tests are pretty simple, and exercise various simple PMEs on the type.

Run the unit tests from Visual Studio

Right-click on the test project and select Set as StartUp Project from the menu. Then, press F5 or click the Run button to begin execution.

The default web browser will open up, the tests will run, and the window will stay open. When you are satisfied, close the browser. You’ve just run some simple tests!

Running unit tests from the Visual Studio command line

More interesting is being able to automate the tests: through MSBuild, we’ve added a task that can control the browser and save out the log file(s) from the unit tests when they run.

To do this, you need a few things:

• The Visual Studio command prompt open.
• The full path to the test project.

Open the command prompt

Personally, I always pin the Visual Studio 2008 tools command prompt next to my Visual Studio taskbar icons.

You can start it from the Start Menu, under the tools for the Visual Studio version you are using.

Alternatively, make sure MSBuild is in your path.

Or, start a command prompt and then move to your 32-bit Program Files, then ‘Visual Studio 9.0’, then VC. Run ‘vcvarsall.bat x86’

Note: all these command prompts should be 32-bit, even on a x64 machine. Silverlight is a 32-bit world today.

Move to the test project

To get the full path to the test project, I just right-click on the test project in Visual Studio, then Open Folder in Windows Explorer. I copy the path from the resulting Explorer dialog’s crumb navigation bar.

Now, inside the command prompt window, move to that path:

pushd (PASTE PATH HERE) <enter>

To run the unit tests in the default browser, simply type

msbuild /t:test

and press Enter.

You’ll see the browser open, quickly run some tests, and then close. Here’s what it looks like, captured in the middle of the 5-second test run:

And afterwards, you’ll see that Msbuild reports success, and you can read the test to see that 3 passing tests were reported, out of 3 total tests.

Running tests in Google Chrome

It’s easy! Just set the browser property to Chrome.

msbuild /t:test /p:browser=chrome

And just like that, Chrome opens up and runs the tests.

Running tests in Mozilla Firefox

Just set the browser to Firefox.

msbuild /t:test /p:browser=firefox

Tag Expressions

A nice feature to help select a subset of tests is the Tag Expression syntax. By specifying a tag expression at the command prompt, you can include and exclude tests that are marked with the Tag attribute found in Microsoft.Silverlight.Testing.

Also, tags implicitly exist for all test method names, short and full.

So, let’s run the test called TestSetName from our project.

msbuild /t:test /p:tagexpression=TestSetName

You may briefly see indication in the test UI in the browser that a ‘Tag expression’ is in use.

And the build results show that just one test ran:

If you want to run all tests except that one, use this tag expression:

msbuild /t:test /p:tagexpression=!TestSetName

Cool, and easy!

Test results files

Another nice feature of running the tests through MSBuild is that you’ll see test result files (end in *.trx) inside the same folder as the test page for the application.

Similar and conformant to the Visual Studio *.trx format, you can parse and work with this data to understand execution times, results, and read other information. Unfortunately, you cannot open these files in Visual Studio 2010 Beta 2, but they do open in Visual Studio 2008. Note that there isn’t any real test integration with VS here: this is just an informative display.

Here’s a directory with several test result files (plus some coverage stuff we’ll get to later):

You can open up the TestResults trx file and see what kind of information is in it:

And here’s the results file opened in Visual Studio:

Preparing for Code Coverage

Ripe for a Visual Studio add-in, this process requires us modifying the test project’s .csproj file some. Instructions are the same for Visual Studio.

We need to manually select the assembly to be instrumented by setting a property. The assembly to be instrumented must not be signed, and not have a strong name. In this example, the assembly is SilverlightClassLibrary3.

To make changes to the test project, to specify this, first unload the project by right-clicking on the test project and selecting the Unload option:

Then, right-click the project file that is ‘(unavailable) and select ‘Edit’.

Now you’ll see the XML data for the project. Scroll down in the template to where there is a commented out ItemGroup, and some comments about the code coverage support. Remove the comments from the ItemGroup:

And now, change the Include statement from SilverlightClassLibrary1 to whatever your assembly to instrument is called. In our example here, it is called SilverlightClassLibrary3.

Now, that’s it. Let’s close the file and then right-click the project again and select Reload Project:

Now we’re ready to go!

Running Silverlight Code Coverage

Just like the msbuild /t:test from above, we have a similar target named CoverageTest and CoverageView. CoverageTest collects the data, while CoverageView collects the coverage data and then shows the results in an application that explores the hit and not hit portions of your source code.

Let’s collect coverage!

Note: This is assuming that you have a high-level SKU of Visual Studio 2010 Beta 2 installed. The coverage tools depend on the Static Analysis Tools that ship in the beta. You will receive an error if you run this on a machine without those tools. We’ll look for a better experience in the future.

Remember, the same properties from above – browser and tag expression – still can apply and work in the coverage targets.

msbuild /t:coveragetest

Here is what it will look like if everything line up. Unfortunately, the coverage experience is a very early preview and very flaky in some situations due to the dependency on beta components. We also haven’t had I admit enough time to iron out all the issues customers may experience.

You see the Instrumentation messages come out, then the RunTests target, then the coverage data is merged and things should be successful.

If that worked, it is safe to assume that the view target will also work. It will re-run all the tests and instrument again as well.

msbuild /t:coverageview

Now you’ll see the viewer popup, that lets you drill into types and methods to see what is hit (cyan) or not hit (red), to spot code that your tests are missing:

You’ll find a Coverage.xml file in the same directory where the test results go. This is the data that is used by the viewer application. You’ll see in the XML file a set of ‘visited’ blocks, and other information, in the file:

More to come soon!

Download the Silverlight Toolkit November 2009 Release Today

The Silverlight Toolkit is a collection of Silverlight controls, components and utilities that help make Silverlight development a little easier, more fun, and add value outside the regular Silverlight release cycle.

The sixth release of the Silverlight Toolkit, the November 2009 release targets Silverlight 3. There is also a release available that targets the new Silverlight 4 Beta for developers.

Resources of note:

• Learn more about the Silverlight Toolkit
• Download the November 2009 Release
• Get started with Silverlight development
• Participate in the controls community at Silverlight.net
• Check out questions and answers on Stack Overflow using the ‘silverlight-toolkit’ tag
• The Issue Tracker can be used to report issues, add to the feature wish list, and vote on the work to be done by the Microsoft team

Hope you enjoy our new release!

If you deliver your source ultimately to a Visual Studio 2008-targeted source project, or have issue adopting a beta product until its release, this is a pain.

I wrote a tool last month for round-trip converting Silverlight-specific solutions and .csproj files between the versions, and want to share it as-is, with no warranty, hoping someone finds it useful.

Here are two potential solutions for dealing with the conversion issue, actually the second builds from the first.

Use Source Control

If your project is not churning that often in added and removed files, source control is the easiest solution to this problem!

• Open your solution in Visual Studio 2010
• Allow the conversion wizard to complete
• When checking in, carefully revert the .csproj and .sln files (assuming no changes to their contents)

Easy enough. But not crisp enough!

Use my hacky program

Now assuming you are already using source control, then you can consider using my script/tool for performing the round-trip conversion. You still want to have everything in source control – you just never know.

Before we start

• This program will work on the current directory and all subdirectories
• It will modify read-only files
• It will consider all .csproj and .sln files, potentially destroying non-Silverlight project files – so use caution if the current directory or sub-directory contains other project types
• This is C#-only, though a similar exercise for .vbproj files would not be that bad
• This will delete .suo and .user files that may contain version-specific binary data, so you may lose your local settings (such as the current startup project you have set locally)
• This ‘works on my machine’ and I am not responsible for data loss in any way
• This code is not efficient nor elegant. Get over it! I did!

Download the binary and source

ThereAndBackAgain.zip [21.8K, Zip]

I have included the source, Ms-PL licensed, because though awful, maybe someone can do something much better with it!

Convert all C# projects and solutions to Visual Studio 2010

Move into the root directory of your solution in a command prompt window, and provide the path to the ThereAndBackAgain.exe file. It will recurse the current directory.

pushd c:\myEnlistment\myProject\Silverlight\

c:\tools\ThereAndBackAgain.exe 2010 <enter>

You’ll see a quick list of what is changed. You can run this on a directory tree that is already converted, and it should not be affected.

Convert back to Visual Studio 2008

Pretty similar:

pushd c:\myEnlistment\myProject\Silverlight\

c:\tools\ThereAndBackAgain.exe 2008 <enter>

Final note

This works for me. Uh and so no promises beyond that. I literally just diff’d a new VS 08 and VS 2010 Silverlight project and wrote something to move between the two. Nothing fancy.

If you go this route, remember to convert back your projects and solutions using the tool before checking in! You don’t want to break the build, or a teammates’ development experience.

Hope this helps. Again, I wrote this script specifically to meet my needs, but it is FAR from production-ready. You are on your own, feel free to take and run with this.

I recently did hear a few complaints that the Silverlight Unit Test Framework site on the MSDN Code Gallery is a little out of date. I hear you, and am going to try to refresh the wiki and documentation a little bit.

In the meantime, I’ve updated the site with the latest Silverlight 2 Unit Test Framework binaries for download. Here’s a direct link to the download. I don’t have any updated bits available for the Silverlight 3 Beta at this time.

What’s new in the July 2009 bits of the Silverlight Unit Test Framework?

• Support for the [Timeout(...)] attribute on test methods.
• Improvements to the Test Service interface. The service now has an asynchronous reporting phase that allows for more robust automation options (details coming soon).
• Minor interface changes
• Minor bug fixes

I’ll try and get updated templates produced this month as well. Hope this is useful!

On the Silverlight Toolkit team, we leave it up to individual team members to decide what core development environment they want. By having the Silverlight 2 and Silverlight 3 SDKs checked into our source enlistment, our TFS build server can produce Silverlight 2 and Silverlight 3 binaries, and we can also msbuild the same bits on our machines, regardless of the Silverlight Tools, SDK, or runtime installed on our machines.

I blogged about this back in late January about “building Silverlight code on machines without the SDK installed,” though really it was more about “building Silverlight code for multiple Silverlight versions.”

Select your primary development environment

Decide whether you would like to do primarily Silverlight 2 or 3 development. Then, install the accompanying tools install, and Expression Blend version.

It is time consuming to move between the two environments, but you can actually uninstall/reinstall the shipping runtime or developer runtime versions of Silverlight if you need to test an app in a specific configuration, without having to do a full reinstall of the tools.

Preparing your source enlistment

On the Toolkit, we have a directory of external tools and engineering resources. One of these contains the Silverlight SDK’s assemblies, libraries, and build scripts, as shown in the video.

• Create a directory to store the MsBuild assets for Silverlight, and copy in the files from %programfiles%MSBuild\Microsoft\Silverlight\v2.0.
• Copy the “Reference Assemblies” directory from %programfiles%\Microsoft SDKs\Silverlight\v2.0\ into the tools directory.
• Copy the “Libraries” directory from %programfiles%\Microsoft SDKs\Silverlight\v2.0\ into the directory.

You can then use relative paths in your projects or custom build targets to get things rolling.

How we use a custom <Import /> element in projects

Our source code enlistment is broken up into a Silverlight 2 and a Silverlight 3 branch of nearly-identical trees of code. By using a centralized msbuild .targets file, we’re able to leave it up to a single file in the branch to select which verison of Silverlight the application should build with.

This actually even works when building in Visual Studio, so opening a project that uses this method, while using the Silverlight 3 Tools, but building a Silverlight 2 app, will build with the verison 2 SDK. Do note that the design-time experience won’t work in this scenario.

Silverlight.CSharp.targets

All of our VB and C# source projects for Silverlight, within the source enlistment, reference a relative path, typically something like ..\..\Silverlight.CSharp.targets, instead of the standard Silverlight CSharp targets from the Silverlight MSBuild scripts.

Inside this relative path, it defines the properties. For Silverlight 2:

<Project
  ToolsVersion="3.5"
  DefaultTargets="Build"
  xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>
    <!-- Define the ExternalTools property first -->
    <SilverlightBuildResources>$(ExternalTools)\Silverlight\v2.0\</SilverlightBuildResources>
    <TargetFrameworkDirectory>$(SilverlightBuildResources)Reference Assemblies\</TargetFrameworkDirectory>
    <TargetFrameworkSDKDirectory>$(SilverlightBuildResources)Libraries\Client\</TargetFrameworkSDKDirectory>
    <SilverlightRuntimeVersion>2.0.31005.0</SilverlightRuntimeVersion>
  </PropertyGroup>
  <Import Project="$(SilverlightBuildResources)Microsoft.Silverlight.CSharp.targets"/>

</Project>

And for Silverlight 3 Beta:

<Project
  ToolsVersion="3.5"
  DefaultTargets="Build"
  xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>
    <!-- Define the ExternalTools property first -->
    <SilverlightBuildResources>$(ExternalTools)\Silverlight\v3.0\</SilverlightBuildResources>

    <TargetFrameworkDirectory>$(SilverlightBuildResources)Reference Assemblies\</TargetFrameworkDirectory>
    <TargetFrameworkSDKDirectory>$(SilverlightBuildResources)Libraries\Client\</TargetFrameworkSDKDirectory>
    <SilverlightRuntimeVersion>3.0.40217.0</SilverlightRuntimeVersion>
  </PropertyGroup>
  <Import Project="$(SilverlightBuildResources)Microsoft.Silverlight.CSharp.targets"/>
</Project>

Hope this helps and is useful to you and your development team.

This provides a very nice experience when using Visual Studio 2008 and Expression Blend 3, since the Toolkit’s controls appear alongside all other Silverlight SDK controls now.

I wanted to take a few minutes and record a few questions and answers about the new experience. Let me know if there are some other questions you’d like answered.

Why are there two setup downloads for the March 2009 release?

The March 2009 release is available for targeting Silverlight 2 applications (recommended for most developers and designers working on current production Silverlight 2 apps), and a Silverlight 3 Beta release.

Since the target platform is important, you can make a choice. Of course, both the Silverlight 2 and Silverlight 3 Beta installs for the Silverlight Toolkit support side-by-side; however, the Visual Studio 2008′s Silverlight Tools do not support “multi-targeting,” so you really should decide and stick to a single target development environment for Silverlight coding today.

What are the system requirements?

The Silverlight Toolkit only requires a recent version of the .NET framework to install. However, for the best experience, you should have one of these development environments installed and configured:

• Visual Studio 2008 SP1 with the Silverlight Tools (Silverlight 2 or Silverlight 3 Beta)
• Visual Web Developer Express with the Silverlight Tools (Silverlight 2 or Silverlight 3 Beta)
• Expression Blend 2 SP1 with Silverlight 2
• Expression Blend 3 MIX ’09 Preview with Silverlight 3 Beta

More information about these tools and downloads is available at http://silverlight.net/getstarted/silverlight3/default.aspx.

You can install the Silverlight Toolkit before or after the Silverlight Tools installation.

What’s with the namespace change to System.Windows.Controls?

As the Silverlight Toolkit has begun delivering controls into the official Silverlight SDK, it became apparent that we should be consistent across the Silverlight platform with regard to the namespace used for the Microsoft controls. As a result, we decided to make this namespace change along with the new “.Toolkit” assembly name scheme.

Where’s the AutoCompleteBox control? How about TreeView?

Some of the “Stable” controls were moved to the official Microsoft Silverlight 3 Beta SDK, since they are trending towards the “Mature” quality band. As a result, the controls live in different assemblies depending on whether you are performing Silverlight 2 or Silverlight 3 Beta development.

In the Silverlight 2 Toolkit March 2009 release, AutoCompleteBox is in System.Windows.Controls.Input.Toolkit. TreeView is in System.Windows.Controls.Toolkit.

In the Silverlight 3 Toolkit March 2009 release, AutoCompleteBox is in System.Windows.Controls.Input. TreeView is in System.Windows.Controls. These assemblies are part of the Silverlight 3 Beta SDK and DO NOT require installation of the Silverlight Toolkit.

The Silverlight 2 controls are compatible with Silverlight 3, so existing applications will continue to work – but we do highly recommend that you update to the appropriate Silverlight Toolkit for your target Silverlight version, since we do add version-enhanced features, such as animation easing for the Silverlight Toolkit charts in the Silverlight 3 Beta.

More information about the assembly and namespace name changes is available in this post by Shawn Burke.

What is installed with the Silverlight Toolkit now?

You’ll find the same basics as before, plus some. You’ll find these in the “Microsoft Silverlight 3 Toolkit March 2009″ (or similarly named folder for the Silverlight 2 version) folder in your Start Menu.

• New “Welcome” page with general information about the release, plus a link to the breaking changes and release notes for the release.
• Links to the CodePlex site for the Toolkit, plus the Silverlight.net discussion forums
• A link to the sample application for the Toolkit, served from the local system
• Links to Zip files containing the control source code and/or the sample source code
• The documentation for the Toolkit controls in CHM format. The documentation file no longer requires the “Unlock” workaround step on Windows Vista and Windows 7. Do note that the documentation for former Silverlight Toolkit controls that now appear in the Silverlight 3 SDK, such as AutoCompleteBox, are now located in the official Silverlight documentation. An offline download of the SDK documentation is also available.

What rocked about the Zip?

Well, in my mind, it was:

• Transparent experience
• Nothing fancy
• Lightweight. Nothing to install, so if you didn’t want it anymore, you could just delete the files, for instance.

What was so bad about the Zip?

• No integration into Visual Studio or Expression Blend out-of-the-box, without doing some manual file copy or registry work
• Confusing to users used to a setup experience
• CHM documentation files downloaded in a Zip require “Unlocking” before they work. Until then, they appear broken.

Would you consider offering releases in a Zip file, optionally, still?

We’re open to the idea. Especially now that there’s an Eclipse Silverlight development experience, we do need to be mindful of the need to use the releases on other platforms.

Since our packaging infrastructure was initially designed to output these nice .Zip files, it wouldn’t be too tough for us to get this going. We’ll see what the customer requests look like.

How do I select whether I want to get the source code to the controls?

There is an installation option for a feature called “Source code,” you can click on the box to the left of the item and remove the component if you would not like to install the source package.

If you do select this feature (per the default), a .Zip file is placed on the system that contains the source code. You can extract the zip file into a location of your selection to build or view the source.

As always, the source is also available on the Silverlight Toolkit CodePlex site.

What about Microsoft Expression Blend integration?

The Blend 3 MIX09 Preview release includes support for having the Silverlight Toolkit appear in the “Custom Controls” tab of the Asset Library. This is only available for Silverlight 3 Beta, not the Silverlight 2 / Expression Blend 2 product.

There is some really great design time support in this release. For instance, if you just drop a “Chart” control onto your Blend design canvas, you’re greeted with a chart that has simple design time data! It might look a little like one of those “the most bars anywhere” cell phone commercials, but it is very helpful for styling.

What powers the installer?

We leveraged the open source Windows Installer XML (WiX) toolset, an excellent and easy way to build Windows Installer packages. Kudos to Eric St. John, a Microsoft developer who contributes to WiX, for excellent advice, btw!

This was important to our small development team, since we wanted to spend time working on new features like awesome design-time integration and new controls like accordion instead of assigning a developer to the setup full-time.

Hope you like the new experience. Let us know!

Great stuff for designers, this prototype tool enables designers to use Blend day-to-day for getting immediate feedback and excellent tooling support, while being able to round-trip themes, from Blend to ISM to Blend again.

This tool is not guaranteed to be lossless. Use it at your own risk. It will take a XAML file that Blend appreciates (details on Mehdi’s blog):

• No x:Key attributes
• References to other styles by key name become fully qualified resource lookups: from ScrollViewerStyle to System.Windows.Controls.ScrollViewer
• There are some assumption about naming
• Adding explicit references to other styles

… and convert it into an ISM theme.

Today I’m finally blogging a prototype version of the app, a work-in-progress, hoping that maybe others will have the time to make better use of it than I have. I have grand visions for the tool: add a file system watcher, monitor file saves in Blend, and then immediately msbuilding updated ISM theme assembly files. Updating sample apps behind the scenes. Real-time theme previews. None of those grand features are in the download. Give it time.

Download a VS’08 console project with the source (Ms-PL)
Read Mehdi’s guide on ISM styles

To run, use either:
ToolkitTheme.exe App.xaml /t:ism MyIsmTheme.xaml
ToolkitTheme.exe MyIsmTheme.xaml /t:blend App.xaml

Since this is a proof-of-concept prototype, I’m only releasing source for now, assuming you’re a developer at heart – no designer binaries. Let me know if you have any feedback on the tool!

The availability of distributed content delivery network (CDN)-like services for files to developers has only just started to begin. S3 was a first step; Silverlight Streaming provided some interesting concepts.

I am wondering now if anyone else is experimenting with two very recent areas pushing this space:

Mosso: “The Rackspace Cloud” – offers distribution on Limelight. $0.22/GB for the first few terabytes.

CloudFront by Amazon: varies by edge location, starts at $0.17/GB for most locations.

I’ve been able to host Silverlight content and applications just great with these, and the costs are so very affordable.

CloudFront connects directly to your S3 storage. S3 is in use in so many places now that I can write a simple Silverlight application, use S3 for all of its data needs, and make the application independent of its host application server. In fact, it can be entirely served and hosted through S3.

Are there other services I should be aware of? I figure that Limelight and Akamai directly only deal with large customers, and do not cater to a development audience.

Eric Hexter was wondering if I could figure out any build time differences, and so what I did was download the Silverlight Toolkit source code from http://www.codeplex.com/Silverlight/ and build on a few different systems.

This isn’t scientific, but the machines were all similar enough (Core 2 Duo or Quad Core; building on a single core only, not a parallelized build) that I feel OK at least sharing the numbers I received in a single build attempt.

Not conclusively awesome; a lot of the build time is actually spent performing code analysis, and so your own build might be more or less disk read dependent.

Part of the Silverlight SDK can be copied into your source tree to build projects on machines without requiring Silverlight or the SDK. This is great for continuous integration environments and build labs where having an independent build is key.

I’ve compiled a quick screencast (6:07) that demonstrates preparing a directory to check in the proper SDK components, updating a C# project file, and then proving the result by uninstalling the Silverlight SDK.

Walkthrough video

6:07, 60MB, HD 720p (Download WMV)

Properties respected by the Silverlight MsBuild targets

The Silverlight build system respects these build properties that can override the standard SDK locations:

The runtime version is used when generating the application manifest and HTML test page.

Preparing your source enlistment

On the Toolkit, we have a directory of external tools and engineering resources. One of these contains the Silverlight SDK’s assemblies, libraries, and build scripts, as shown in the video.

• Create a directory to store the MsBuild assets for Silverlight, and copy in the files from %programfiles%MSBuild\Microsoft\Silverlight\v2.0.
• Copy the “Reference Assemblies” directory from %programfiles%\Microsoft SDKs\Silverlight\v2.0\ into the tools directory.
• Copy the “Libraries” directory from %programfiles%\Microsoft SDKs\Silverlight\v2.0\ into the directory.

You can then use relative paths in your projects or custom build targets to get things rolling.

Updating projects

Depending on your build system, you’ll want to update your custom targets or project files. In the video I’m simply modifying the .csproj file to add the necessary properties and modify the import statement.

Add properties

I’d scroll through the .csproj and insert the new properties right before the Import statement that pulls in the Silverlight build targets. Here are the properties defined; the SilverlightBuildResources property is my own made-up name that I’m using to store the relative path to the new building bits:

  <PropertyGroup>
    <SilverlightBuildResources>..\Build\</SilverlightBuildResources>
    <TargetFrameworkDirectory>$(SilverlightBuildResources)Reference Assemblies\</TargetFrameworkDirectory>
    <TargetFrameworkSDKDirectory>$(SilverlightBuildResources)Libraries\Client\</TargetFrameworkSDKDirectory>
    <SilverlightRuntimeVersion>2.0.31005.0</SilverlightRuntimeVersion>
  </PropertyGroup>

Import the new Silverlight build target

Silverlight projects import the Silverlight MsBuild targets from the central MsBuild extensions directory, so we just need to update the import to instead come from the source tree:

  <Import Project="$(SilverlightBuildResources)Microsoft.Silverlight.CSharp.targets" />
  <!--
	This is the default provided for new Silverlight projects:
  <Import Project="$(MSBuildExtensionsPath)\Microsoft\Silverlight\v2.0\Microsoft.Silverlight.CSharp.targets" />
  -->

Build

You’re all set! And, for future reference: you can use this to build applications targeting multiple versions of Silverlight from the same tree. But more on that later.

I’ve compiled a quick screencast (6:07) that demonstrates preparing a directory to check in the proper SDK components, updating a C# project file, and then proving the result by uninstalling the Silverlight SDK.

Walkthrough video

6:07, 60MB, HD 720p (Download WMV)

Properties respected by the Silverlight MsBuild targets

The Silverlight build system respects these build properties that can override the standard SDK locations:

The runtime version is used when generating the application manifest and HTML test page.

Preparing your source enlistment

On the Toolkit, we have a directory of external tools and engineering resources. One of these contains the Silverlight SDK’s assemblies, libraries, and build scripts, as shown in the video.

• Create a directory to store the MsBuild assets for Silverlight, and copy in the files from %programfiles%MSBuild\Microsoft\Silverlight\v2.0.
• Copy the “Reference Assemblies” directory from %programfiles%\Microsoft SDKs\Silverlight\v2.0\ into the tools directory.
• Copy the “Libraries” directory from %programfiles%\Microsoft SDKs\Silverlight\v2.0\ into the directory.

You can then use relative paths in your projects or custom build targets to get things rolling.

Updating projects

Depending on your build system, you’ll want to update your custom targets or project files. In the video I’m simply modifying the .csproj file to add the necessary properties and modify the import statement.

Add properties

I’d scroll through the .csproj and insert the new properties right before the Import statement that pulls in the Silverlight build targets. Here are the properties defined; the SilverlightBuildResources property is my own made-up name that I’m using to store the relative path to the new building bits:

  <PropertyGroup>
    <SilverlightBuildResources>..\Build\</SilverlightBuildResources>
    <TargetFrameworkDirectory>$(SilverlightBuildResources)Reference Assemblies\</TargetFrameworkDirectory>
    <TargetFrameworkSDKDirectory>$(SilverlightBuildResources)Libraries\Client\</TargetFrameworkSDKDirectory>
    <SilverlightRuntimeVersion>2.0.31005.0</SilverlightRuntimeVersion>
  </PropertyGroup>

Import the new Silverlight build target

Silverlight projects import the Silverlight MsBuild targets from the central MsBuild extensions directory, so we just need to update the import to instead come from the source tree:

  <Import Project="$(SilverlightBuildResources)Microsoft.Silverlight.CSharp.targets" />
  <!--
	This is the default provided for new Silverlight projects:
  <Import Project="$(MSBuildExtensionsPath)\Microsoft\Silverlight\v2.0\Microsoft.Silverlight.CSharp.targets" />
  -->

Build

You’re all set! And, for future reference: you can use this to build applications targeting multiple versions of Silverlight from the same tree. But more on that later.

The task presented here is used (along with others) to help improve developer efficiency, cut down on simple coding mistakes, and specialize a number of functions to automation and tasks. This post is kind of like learning about how sausage is made: this is for power users and control developers who have an interest in geek’n out with this.

This particular post helps improve the development process for controls by letting us separate out the actual styles, so we don’t spend so much time worrying about merge conflicts and diffs.

Merging resources into generic.xaml

As recently noted on the Silverlight.net forums, the source code download for the Silverlight Toolkit sheds some light on an interesting “MergeDefaultStyles” task (and DefaultStyle item type) used to merge all the different control .Xaml files into one build file.

This allows us to bundle several controls in a single library, but not worry about merging source code changes for several templates in a single generic.xaml: TreeView, AutoCompleteBox, and other controls each have their own XAML resource dictionaries that contain their default styles and template: AutoCompleteBox.xaml is merged at build time into the generic.xaml, and so on.

I am assuming that you’re already familiar enough with msbuild to create your own tasks… here goes. Also, do download the toolkit source code package – although the package does not include the custom targets to use this task, it does include the individual resource dictionaries used by the controls.

The MergeDefaultStylesTask

The task has a few inputs:

• ProjectDirectory, required; sets the directory of the project where the generic.xaml resides.
• DefaultStyles array of ITaskItem’s; represents the items that are marked with the DefaultStyle build action.

And the eventual output is the updating of the generic.xaml file.

The task references the typical MsBuild libraries, including Microsoft.Build.Framework, engine, and utilities. In our implementation, we also interact with our Visual Studio Team Foundation Server (TFS): however I’ve stripped that from this example, for simplicity sake, and instead just removed the read-only flag on the generic.xaml file when writing it.

Here’s MergeDefaultStylesTask.cs:

// (c) Copyright Microsoft Corporation.
// This source is subject to the Microsoft Public License (Ms-PL).
// Please see http://go.microsoft.com/fwlink/?LinkID=131993 for details.
// All other rights reserved.

using System;
using System.Collections.Generic;
using System.Diagnostics.CodeAnalysis;
using System.IO;
using System.Text;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;

namespace Engineering.Build.Tasks
{
    /// <summary>
    /// Build task to automatically merge the default styles for controls into
    /// a single generic.xaml file.
    /// </summary>
    public class MergeDefaultStylesTask : Task
    {
        /// <summary>
        /// Gets or sets the root directory of the project where the
        /// generic.xaml file resides.
        /// </summary>
        [Required]
        public string ProjectDirectory { get; set; }

        /// <summary>
        /// Gets or sets the project items marked with the "DefaultStyle" build
        /// action.
        /// </summary>
        [Required]
        public ITaskItem[] DefaultStyles { get; set; }

        /// <summary>
        /// Initializes a new instance of the MergeDefaultStylesTask class.
        /// </summary>
        public MergeDefaultStylesTask()
        {
        }

        /// <summary>
        /// Merge the project items marked with the "DefaultStyle" build action
        /// into a single generic.xaml file.
        /// </summary>
        /// <returns>
        /// A value indicating whether or not the task succeeded.
        /// </returns>
        [SuppressMessage("Microsoft.Design", "CA1031:DoNotCatchGeneralExceptionTypes", Justification = "Task should not throw exceptions.")]
        public override bool Execute()
        {
            Log.LogMessage(MessageImportance.Low, "Merging default styles into generic.xaml.");

            // Get the original generic.xaml
            string originalPath = Path.Combine(ProjectDirectory, Path.Combine("themes", "generic.xaml"));
            if (!File.Exists(originalPath))
            {
                Log.LogError("{0} does not exist!", originalPath);
                return false;
            }
            Log.LogMessage(MessageImportance.Low, "Found original generic.xaml at {0}.", originalPath);
            string original = null;
            Encoding encoding = Encoding.Default;
            try
            {
                using (StreamReader reader = new StreamReader(File.Open(originalPath, FileMode.Open, FileAccess.Read)))
                {
                    original = reader.ReadToEnd();
                    encoding = reader.CurrentEncoding;
                }
            }
            catch (Exception ex)
            {
                Log.LogErrorFromException(ex);
                return false;
            }

            // Create the merged generic.xaml
            List<DefaultStyle> styles = new List<DefaultStyle>();
            foreach (ITaskItem item in DefaultStyles)
            {
                string path = Path.Combine(ProjectDirectory, item.ItemSpec);
                if (!File.Exists(path))
                {
                    Log.LogWarning("Ignoring missing DefaultStyle {0}.", path);
                    continue;
                }

                try
                {
                    Log.LogMessage(MessageImportance.Low, "Processing file {0}.", item.ItemSpec);
                    styles.Add(DefaultStyle.Load(path));
                }
                catch (Exception ex)
                {
                    Log.LogErrorFromException(ex);
                }
            }
            string merged = null;
            try
            {
                merged = DefaultStyle.Merge(styles).GenerateXaml();
            }
            catch (InvalidOperationException ex)
            {
                Log.LogErrorFromException(ex);
                return false;
            }

            // Write the new generic.xaml
            if (original != merged)
            {
                Log.LogMessage(MessageImportance.Low, "Writing merged generic.xaml.");

                try
                {
                    // Could interact with the source control system / TFS here
                    File.SetAttributes(originalPath, FileAttributes.Normal);
                    Log.LogMessage("Removed any read-only flag for generic.xaml.");

                    File.WriteAllText(originalPath, merged, encoding);
                    Log.LogMessage("Successfully merged generic.xaml.");
                }
                catch (Exception ex)
                {
                    Log.LogErrorFromException(ex);
                    return false;
                }
            }
            else
            {
                Log.LogMessage("Existing generic.xaml was up to date.");
            }

            return true;
        }
    }
}

With the task in place, now we just need to add the DefaultStyle implementation and build the task assembly.

DefaultStyle does the heavy lifting

The type DefaultStyle is very LINQ-y and uses XLinq to handle parsing XAML, managing namespaces, and also the merging of multiple instances. Here’s DefaultStyle.cs, that should be included in the project (author: Ted Glaza):

// (c) Copyright Microsoft Corporation.
// This source is subject to the Microsoft Public License (Ms-PL).
// Please see http://go.microsoft.com/fwlink/?LinkID=131993 for details.
// All other rights reserved.

using System;
using System.Collections.Generic;
using System.Globalization;
using System.IO;
using System.Linq;
using System.Xml.Linq;

namespace Engineering.Build
{
    /// <summary>
    /// DefaultStyle represents the XAML of an individual Control's default
    /// style (in particular its ControlTemplate) which can be merged with other
    /// default styles).  The XAML must have a ResourceDictionary as its root
    /// element and be marked with a DefaultStyle build action in Visual Studio.
    /// </summary>
    public partial class DefaultStyle
    {
        /// <summary>
        /// Root element of both the default styles and the merged generic.xaml.
        /// </summary>
        private const string RootElement = "ResourceDictionary";

        /// <summary>
        /// Gets or sets the file path of the default style.
        /// </summary>
        public string DefaultStylePath { get; set; }

        /// <summary>
        /// Gets the namespaces imposed on the root element of a default style
        /// (including explicitly declared namespaces as well as those inherited
        /// from the root ResourceDictionary element).
        /// </summary>
        public SortedDictionary<string, string> Namespaces { get; private set; }

        /// <summary>
        /// Gets the elements in the XAML that include both styles and shared
        /// resources.
        /// </summary>
        public SortedDictionary<string, XElement> Resources { get; private set; }

        /// <summary>
        /// Gets or sets the history tracking which resources originated from
        /// which files.
        /// </summary>
        private Dictionary<string, string> MergeHistory { get; set; }

        /// <summary>
        /// Initializes a new instance of the DefaultStyle class.
        /// </summary>
        protected DefaultStyle()
        {
            Namespaces = new SortedDictionary<string, string>(StringComparer.OrdinalIgnoreCase);
            Resources = new SortedDictionary<string, XElement>(StringComparer.OrdinalIgnoreCase);
            MergeHistory = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
        }

        /// <summary>
        /// Load a DefaultStyle from the a project item.
        /// </summary>
        /// <param name="path">
        /// Path of the default style which is used for reporting errors.
        /// </param>
        /// <returns>The DefaultStyle.</returns>
        public static DefaultStyle Load(string path)
        {
            DefaultStyle style = new DefaultStyle();
            style.DefaultStylePath = path;

            string xaml = File.ReadAllText(path);
            XElement root = XElement.Parse(xaml, LoadOptions.PreserveWhitespace);
            if (root.Name.LocalName == RootElement)
            {
                // Get the namespaces
                foreach (XAttribute attribute in root.Attributes())
                {
                    if (attribute.Name.LocalName == "xmlns")
                    {
                        style.Namespaces.Add("", attribute.Value);
                    }
                    else if (attribute.Name.NamespaceName == XNamespace.Xmlns.NamespaceName)
                    {
                        style.Namespaces.Add(attribute.Name.LocalName, attribute.Value);
                    }
                }

                // Get the styles and shared resources
                foreach (XElement element in root.Elements())
                {
                    string name = (element.Name.LocalName == "Style") ?
                        GetAttribute(element, "TargetType", "Key", "Name") :
                        GetAttribute(element, "Key", "Name");
                    if (style.Resources.ContainsKey(name))
                    {
                        throw new InvalidOperationException(string.Format(
                            CultureInfo.InvariantCulture,
                            "Resource \"{0}\" is used multiple times in {1} (possibly as a Key, Name, or TargetType)!",
                            name,
                            path));
                    }
                    style.Resources.Add(name, element);
                    style.MergeHistory[name] = path;
                }
            }

            return style;
        }

        /// <summary>
        /// Get the value of the first attribute that is defined.
        /// </summary>
        /// <param name="element">Element with the attributes defined.</param>
        /// <param name="attributes">
        /// Local names of the attributes to find.
        /// </param>
        /// <returns>Value of the first attribute found.</returns>
        private static string GetAttribute(XElement element, params string[] attributes)
        {
            foreach (string name in attributes)
            {
                string value =
                    (from a in element.Attributes()
                     where a.Name.LocalName == name
                     select a.Value)
                     .FirstOrDefault();
                if (name != null)
                {
                    return value;
                }
            }
            return "";
        }

        /// <summary>
        /// Merge a sequence of DefaultStyles into a single style.
        /// </summary>
        /// <param name="styles">Sequence of DefaultStyles.</param>
        /// <returns>Merged DefaultStyle.</returns>
        public static DefaultStyle Merge(IEnumerable<DefaultStyle> styles)
        {
            DefaultStyle combined = new DefaultStyle();
            if (styles != null)
            {
                foreach (DefaultStyle style in styles)
                {
                    combined.Merge(style);
                }
            }
            return combined;
        }

        /// <summary>
        /// Merge with another DefaultStyle.
        /// </summary>
        /// <param name="other">Other DefaultStyle to merge.</param>
        private void Merge(DefaultStyle other)
        {
            // Merge or lower namespaces
            foreach (KeyValuePair<string, string> ns in other.Namespaces)
            {
                string value = null;
                if (!Namespaces.TryGetValue(ns.Key, out value))
                {
                    Namespaces.Add(ns.Key, ns.Value);
                }
                else if (value != ns.Value)
                {
                    other.LowerNamespace(ns.Key);
                }
            }

            // Merge the resources
            foreach (KeyValuePair<string, XElement> resource in other.Resources)
            {
                if (Resources.ContainsKey(resource.Key))
                {
                    throw new InvalidOperationException(string.Format(
                        CultureInfo.InvariantCulture,
                        "Resource \"{0}\" is used by both {1} and {2}!",
                        resource.Key,
                        MergeHistory[resource.Key],
                        other.DefaultStylePath));
                }
                Resources[resource.Key] = resource.Value;
                MergeHistory[resource.Key] = other.DefaultStylePath;
            }
        }

        /// <summary>
        /// Lower a namespace from the root ResourceDictionary to its child
        /// resources.
        /// </summary>
        /// <param name="prefix">Prefix of the namespace to lower.</param>
        private void LowerNamespace(string prefix)
        {
            // Get the value of the namespace
            string @namespace;
            if (!Namespaces.TryGetValue(prefix, out @namespace))
            {
                return;
            }

            // Push the value into each resource
            foreach (KeyValuePair<string, XElement> resource in Resources)
            {
                // Don't push the value down if it was overridden locally or if
                // it's the default namespace (as it will be lowered
                // automatically)
                if (((from e in resource.Value.Attributes()
                      where e.Name.LocalName == prefix
                      select e).Count() == 0) &&
                    !string.IsNullOrEmpty(prefix))
                {
                    resource.Value.Add(new XAttribute(XName.Get(prefix, XNamespace.Xmlns.NamespaceName), @namespace));
                }
            }
        }

        /// <summary>
        /// Generate the XAML markup for the default style.
        /// </summary>
        /// <returns>Generated XAML markup.</returns>
        public string GenerateXaml()
        {
            // Create the ResourceDictionary
            string defaultNamespace = XNamespace.Xml.NamespaceName;
            Namespaces.TryGetValue("", out defaultNamespace);
            XElement resources = new XElement(XName.Get(RootElement, defaultNamespace));

            // Add the shared namespaces
            foreach (KeyValuePair<string, string> @namespace in Namespaces)
            {
                // The default namespace will be added automatically
                if (string.IsNullOrEmpty(@namespace.Key))
                {
                    continue;
                }
                resources.Add(new XAttribute(
                    XName.Get(@namespace.Key, XNamespace.Xmlns.NamespaceName),
                    @namespace.Value));
            }

            // Add the resources
            foreach (KeyValuePair<string, XElement> element in Resources)
            {
                resources.Add(
                    new XText(Environment.NewLine + Environment.NewLine + "    "),
                    new XComment("  " + element.Key + "  "),
                    new XText(Environment.NewLine + "    "),
                    element.Value);
            }

            resources.Add(new XText(Environment.NewLine + Environment.NewLine));

            // Create the document
            XDocument document = new XDocument(
                // TODO: Pull this copyright header from some shared location
                new XComment(Environment.NewLine +
                    "// (c) Copyright Microsoft Corporation." + Environment.NewLine +
                    "// This source is subject to the Microsoft Public License (Ms-PL)." + Environment.NewLine +
                    "// Please see http://go.microsoft.com/fwlink/?LinkID=131993 for details." + Environment.NewLine +
                    "// All other rights reserved." + Environment.NewLine),
                new XText(Environment.NewLine + Environment.NewLine),
                new XComment(Environment.NewLine +
                    "// WARNING:" + Environment.NewLine +
                    "// " + Environment.NewLine +
                    "// This XAML was automatically generated by merging the individual default" + Environment.NewLine +
                    "// styles.  Changes to this file may cause incorrect behavior and will be lost" + Environment.NewLine +
                    "// if the XAML is regenerated." + Environment.NewLine),
                new XText(Environment.NewLine + Environment.NewLine),
                resources);

            return document.ToString();
        }

        /// <summary>
        /// Generate the XAML markup for the default style.
        /// </summary>
        /// <returns>Generated XAML markup.</returns>
        public override string ToString()
        {
            return GenerateXaml();
        }
    }
}

Reference the task in your project or targets file

Now, with your task assembly in hand (and available in your source tree), add a UsingTask element to your project.

  <!--
  //
  // Define our custom build tasks
  //
  -->
  <UsingTask
    TaskName="Engineering.Build.Tasks.MergeDefaultStylesTask"
    AssemblyFile="$(EngineeringResources)\Engineering.Build.dll" />

Note: We’ve already defined the EngineeringResources property value elsewhere. You can substitute it with your own relative path as need be.

Next up, add an item group that Visual Studio recognizes to add the DefaultStyle item to the property grid:

  <!-- Add "DefaultStyle" as a Build Action in Visual Studio -->
  <ItemGroup Condition="'$(BuildingInsideVisualStudio)'=='true'">
    <AvailableItemName Include="DefaultStyle" />
  </ItemGroup>

Finally, we have two overridden (and custom) targets for merging the default styles, and for “touching” the default styles:

  <!--
  Merge the default styles of controls (only if any of the DefaultStyle files is
  more recent than the project's generic.xaml file) before compilation
  dependencies are processed.
  -->
  <PropertyGroup>
    <PrepareResourcesDependsOn>
      MergeDefaultStyles;
      $(PrepareResourcesDependsOn);
    </PrepareResourcesDependsOn>
  </PropertyGroup>
  <Target
    Name="MergeDefaultStyles"
    Inputs="@(DefaultStyle)"
    Outputs="$(MSBuildProjectDirectory)\generic.xaml">
    <MergeDefaultStylesTask
      DefaultStyles="@(DefaultStyle)"
      ProjectDirectory="$(MSBuildProjectDirectory)" />
  </Target>
  <!--
  Touch DefaultStyles on Rebuild to force generation of generic.xaml.
  -->
  <PropertyGroup>
    <RebuildDependsOn>
      TouchDefaultStyles;
      $(RebuildDependsOn);
    </RebuildDependsOn>
  </PropertyGroup>
  <Target Name="TouchDefaultStyles">
    <Touch Files="@(DefaultStyle)" ForceTouch="true" />
  </Target>

Use the MergeDefaultStyles task in the project

Now, you can change the build actions of the appropriate control .Xaml files (that are resource dictionaries) to use this new task:

When building, you should see the Generic.xaml file update! (Themes\generic.xaml should probably exist before using this task, btw).

This code is offered through the Ms-PL license, but no support from the Silverlight Toolkit is implied. Hope this helps you!