Posted 27 January 2009 Tweet
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.
6:07, 60MB, HD 720p (Download WMV)
The Silverlight build system respects these build properties that can override the standard SDK locations:
|TargetFrameworkDirectory||[Silverlight SDK]\Reference Assemblies\|
The runtime version is used when generating the application manifest and HTML test page.
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.
You can then use relative paths in your projects or custom build targets to get things rolling.
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.
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>
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" /> -->
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.
Jeff Wilcox is a Principal Software Engineer at Microsoft in the Open Source Programs Office, helping Microsoft scale to 10,000+ engineers using, contributing to and releasing open source.