Building Silverlight 2 and Silverlight 3 Beta applications on the same machine

The Silverlight Tools don’t have multi-targeting support today, so if you want to continue building Silverlight 2 applications (for production sites), while experimenting and learning about the Silverlight 3 Beta, it isn’t that easy.

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.

  • http://bigsby.eu Bigsby

    Excelent post!

    I’ll give it a try.

  • http://kalimevole.blogspot.com/ Jan Jelínek

    Thankx for this post. Never ending switching between virtual machine is killing me.

  • http://pagebrooks.com Page Brooks

    Thanks for posting about this, I’ve been needing to do this in a few of my projects.

  • http://endquote.com/ Josh Santangelo

    Nice, but we still need a way for SL2 projects to run in the SL2 runtime and SL3 projects to run in the SL3 runtime without a lot of install/uninstall pain.

    The Flash 10 IDE can publish all the way back to Flash Player 1. VS is a much more capable tool and should be able to do similar without crazy workarounds.

  • http://www.jeff.wilcox.name/ Jeff Wilcox

    @Josh,
    Yeah, my understanding is that this is really only a beta limitation, and this will somehow be addressed in some future Visual Studio changes of some sort.

  • leo

    This situation needs to be addressed , I know the company I work for, we will end up with apps in silverlight 2, 3, 4, 5, and 6,7,8
    please, they need to be compatible …. I still need to have vs.net2003, 2005 and 2008 installed in my computer.

    thanks for the tips
    leo

  • Don

    BTW, SL3 Beta will UNINSTALL SL2 Tools SP1 from VS2008 — a REAL PAIN when you want to do side by side dev. VM is the only solution if you want to do both easily without the ‘install/uninstall’ scheme.

  • http://www.electricscribes.com Richard McSharry

    Hi Jeff,
    This is useful to know, so thanks for taking the time to post it up but I’m afraid I’ll be sticking with my VM’s until MS does versioning properly.

    >”this will somehow be addressed in some future Visual Studio changes of some sort.”

    Do you know if this will happen in a service pack or do we have to wait for VS2010?

    Thanks,
    Richard