Silverlight MsBuild tricks - video

A re-post, I had to switch video streaming services...

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.