| Comments

As we’ve noted before, Visual Studio 2008 doesn’t have multi-targeting support for Silverlight development.  Generally speaking what this means is that if you install the Silverlight 3 tools, you have a Silverlight 3 development environment with VS2008.  True multi-targeting for Silverlight in the IDE will come in Visual Studio 2010 (you can see how that works in this post).

NOTE: Visual Studio 2010 beta 1 (current version available at the time of this writing) does not fully support Silverlight 3 *release version* (also referred to ‘RTM’ or ‘RTW’) development.  There are a few things missing in VS10 beta 1 for full support for SL3 RTW and .NET RIA Services development.  This support will come in later beta builds of VS10 – and no, I have no idea when Visual Studio will be planning on releasing additional beta builds.

But people still want to know how they can build SL2 apps using a single VS2008 machine, no virtual images and without VS2010.  There is a way to do this, but please allow me to set some major caveats.  We must first make sure that what I’m saying here is still that VS2008 does not support multi-targeting IDE development with Silverlight 2 and Silverlight 3.  What I’m also saying is that VS2008 IDE and MSBuild are two different experiences.  MSBuild could care less about an IDE and it just does what it is instructed to do…so let’s instruct it to build Silverlight 2 code, shall we?

Assumptions – please read

Let’s assume this scenario: you are working on SL3 apps so you need the SL3 tools.  Great – install them.  But you also need to either a) support an SL2 application and/or b) for some reason you want to start a new project in Silverlight classic…err, I mean…Silverlight 2.  Okay, let’s proceed with these assumptions and that you already have VS2008 and SL3 dev tools installed.

Step 1: Install the Silverlight 2 SDK

Go grab the Silverlight 2 SDK.  This is different than the Silverlight 2 Tools for Visual Studio.  Don’t install those…you’ll be made at me for no reason if you do.  Again, install the Silverlight 2 SDK.  Once you’ve done that, if you look at your %ProgramFiles%\Microsoft SDKs\Silverlight directory you will see both SDKs installed:

SDK directory with both Silverlight SDKs

Step 2: Create a new project or open your existing Silverlight 2 application

If you are creating a new application and are targeting Silverlight 2 and not taking advantage of all the great new features in Silverlight 3, then create a new Silverlight application.  Obviously (or hopefully so) you cannot choose the Navigation or RIA Services templates…you’ll have to choose the basic Silverlight 2 Application template.  If you are working on an existing SL2 application, open that project.  In this case, VS will convert the project up to an SL3 project.  This is fine for now.

At this point you have your application open in VS and it is basically a SL3 application project.  If you hit F5 at this point, it would build as an SL3 application.

Step 3: Make a copy of the .csproj or .vbproj file

Go to your project’s directory in explorer (fastest way to do this is right-click on the project in Solution Explorer and choose Open Folder in Windows Explorer which is second to the last option by default.  Once in Explorer, make a copy of the .**proj file (either .csproj for C# or .vbproj for Visual Basic).  Name it whatever you want, maybe something like <projectname>-SL2.csproj.

Open that file in notepad or other plain text editor.  You’ll see a line that looks like this (for a default project this is about line 84 – and note the CSharp.Targets will be different if you are using VB):

   1: <Import Project="$(MSBuildExtensionsPath32)\Microsoft\Silverlight\v3.0\Microsoft.Silverlight.CSharp.targets" />

Notice the “v3.0” in the build path?  Alter that only in your copied **proj file to this: (again, noting the difference between CSharp and VB):

   1: <Import Project="$(MSBuildExtensionsPath32)\Microsoft\Silverlight\v2.0\Microsoft.Silverlight.CSharp.targets" />

Basically change the “v3.0” to “v2.0” in that Import node.  This tells the build system to use the SL2 SDK that you installed in Step 1.

Step 4: Modify your build events in VS

At this point, if you still hit F5 you’d be running a SL3 application.  This is still because a) you aren’t opening the altered **proj file we just created in Step 3 and b) you have SL3 tools installed for VS.  What we need to do is instruct Visual Studio to perform an additional build command for your project.

Right-click on the project and select the project properties.  Then from here choose the Build Events tab.  If you really want only a v2 build of your app, then in your post-build event you can enter this (obviously changing to the file name you created in Step 3:

   1: $(MSBuildBinPath)\MSBuild "$(ProjectDir)SilverlightApplication1_2-SL2.csproj"

And when you F5 you’ll end up with a Silverlight 2 XAP.  Go ahead and look at the generated AppManifest.xaml file…it will show you RuntimeVersion=”2.0.31005.0” in the file.

What just happened?

Basically when you F5 in Visual Studio in projects, you are initiating build commands.  Sometimes you’ll see that it just uses csc.exe, but basically these are all build commands in the system.  What we’re doing in Step 4 is telling Visual Studio: When you’re done with that, go ahead and execute this additional build command for me, kthxbye.  Some may look at this and ask if 2 builds are happening.  The answer is YES.  Issuing a build command in VS does its normal process and then we are OVERWRITING THE OUTPUT with our second build.

NOTE: If someone has a better way to tell VS don’t do your normal build but do this instead please post in the comments…I’m not a VS build system pro.

You are definitely overwriting your SL3 compiled bits with the new ones.

Can I build both SL2 and SL3 from the same base?

Sure.  You’ll have to modify the OutputPath setting for your projects so they don’t overwrite each other.  I’m sure if you are asking this question you have a good reason for it as SL2 apps are compatible running under the SL3 runtime without needing to recompile.  I modified my VS IDE app on the Build tab (in the Properties dialog) to put the output in an SL3 folder.  I then modified the OutputPath setting in my file from Step 3 to a folder called SL2.  Now when I build in VS I get both binaries/XAPs created:

post build directories

So I can do what I want with the XAPs now.

So, what’s the catch?  Isn’t this multi-targeting?

Big catches…and NO, this isn’t multi-targeting for VS2008 (at least what we define it for Visual Studio).  Here’s the catches I’ve found:

Your IDE is still a Silverlight 3 IDE environment.  What I mean by this is that VS is doing nothing to prevent you from writing Silverlight 3 code.  Intellisense will be targeted at the SL3 SDK you have installed.  This means if you aren’t paying attention and don’t know what APIs aren’t available in SL2, you can get into trouble VERY fast.  In this event, if you do add code that is SL3 specific your SL2 SDK MSBuild will error out and report back in VS.  Here’s an example of where I added some element-to-element binding in my XAML and VS reports the error for the post-build event (as reported in the Errors output window):

   1: Error    2    The property 'ElementName' does not exist on the type 'Binding' in the XML namespace 'http://schemas.microsoft.com/winfx/2006/xaml/presentation'.    C:\Users\timheuer\Documents\Visual Studio 2008\Projects\SilverlightApplication66_3\SilverlightApplication1_2\MainPage.xaml    10    61    SilverlightApplication1_2
   2: Error    3    The command "C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild "C:\Users\timheuer\Documents\Visual Studio 2008\Projects\SilverlightApplication66_3\SilverlightApplication1_2\SilverlightApplication1_2-SL2.csproj"" exited with code 1.    SilverlightApplication1_2

My SL3 build will still complete fine, remember the SL2 is a post-build event.

The other thing is copying files to an associated web project.  In my steps above, the XAP that would get copied to the ClientBin directory of the web app was the SL3 version.  Honestly I didn’t take the time to worry about that and I know that you could get more creative with your build command to change that…but I wanted to be clear about the output of my steps outlined here.

Assembly references will be another issue.  Remember, VS is doing nothing to prevent you from doing things SL3-specific.  So the assembly reference list you see will include SL3-specific binaries.  Also when you add references in VS, it alters the **proj file.  So each time this happens you’d have to manually edit your copied file to make sure the references are there and are the correct ones for the SL2 SDK.  This can get messy very fast.

What if I just want to continue doing Silverlight 2 development, but view SL3 sites?

Well, then I need to come over there and talk to you about the aweseomeness of Silverlight 3!  But if you must, let me let you know what is going on here.

Short answer: don’t install the SL3 tools.  But again, you’re crazy right?  Silverlight 3 is awesome!

Longer answer…

The Silverlight 2 Tools installer now installs the Silverlight 3 developer runtime, but still installs the SL2 SDK.  Confusing huh?  Bottom line is that in this configuration you can develop SL2 apps in the IDE (with SL2 Intellisense, assembly references, etc) but still be able to view SL3 sites out on the Internet.  How is this possible?  Because the SL2 tools are using the build commands and VS hooks for SL2 SDK (look at the project file and you’ll see it is like above in Step 3).

If you have SL2 tools already installed but don’t have SL3 yet…you cannot install the end-user SL3 runtime on top of a developer runtime (i.e., you cannot ‘upgrade’ a developer runtime to a non-developer runtime).  So you’ll want to install the SL3 developer runtime on top of your SL2 environment in this situation.

Summary

I do not by any means consider this guidance from the Silverlight team.  This is, in fact, a hack.  It’s unsupported, might not work for your situation and as Scott Hanselman says, it may hurt baby kittens.  This information is merely here to really prove a point that you can use MSBuild to build Silverlight 2 applications with the Silverlight 2 SDK.  That’s really the end output here.  The rest is hackery to get VS to do things with that build.  I firmly recommend you develop using Silverlight 3 anyway!

Use at your own risk.  If there are other MSBuild professionals out there that have better methods than post-build events, please comment – again, I’m not a pro in that area, so this was my first pass at testing this out based on questions I got from the community.

Hope this helps and don’t blame me for any injured baby animals.


This work is licensed under a Creative Commons Attribution By license.

| Comments

In a previous post I wanted to call attention to the multi-targeting and design surface improvements for Silverlight developers with Visual Studio 2010 Beta 1.  There has been some comments on that post and a few emails and Twitter replies as well with some great follow-up questions.  I thought I’d post a sort of what works with what information to help you navigate Betaville as a Silverlight developer.

NOTE: We’re talking about Beta technologies here.  That means things may not work, that you shouldn’t count on them for production releases at this time, etc.  In the ‘release early, release often’ mantra of things, I know Microsoft may not follow the ‘often’ side of things, but we sure do release early a lot of things.  It is important to have a perspective that this is for mutual benefit, but also remember that it is beta and things may just not work in harmony.

Being an early adopter usually means you are on the edge.  Standing on that edge of technology comes pain with betas at times.  Add to that multiple beta technologies and you may feel like you are pulling your hair out constantly.  Me too.  Here’s the spectrum of things for a Silverlight developer from a current (as of May 2009) perspective.

Silverlight 2 Development

Silverlight 2 has been released for a while now (since Oct 2008) and is production-ready for you to use.  There is full tool support in both Visual Studio 2008 SP1 (just install the Silverlight tools for VS2008) and Blend 2 SP1.  Both VS2008 and Blend 2 can share project files in harmony and edit back and forth.

The recent Visual Studio 2010 Beta 1 (referred to in this post VS10 so I don’t have to keep typing out beta) will also support Silverlight 2 development.  The Silverlight tools will not install on top of VS10 and you’ll get a warning if you try.  If all you want is Silverlight 2 development in VS10 right now, install the Silverlight 2 SDK and the Silverlight 2 developer runtime.  That’s it…you can then develop Silverlight 2 applications.

Silverlight 3 Development

Silverlight 3 is currently in beta as are the associated tools (Silverlight 3 tools for VS2008 and Blend 3).  A lot of people have been working fine with these in beta and everything works well.  VS2008 can author SL3 projects and Blend 3 can open them no problem.  Both of these are still in beta right now, but it is important to know that Silverlight 3 release tools will be VS2008 and Blend 3.

For VS10 and Silverlight 3, the situation with the tools is similar to Silverlight 2.  The Silverlight tools installer will still not run on VS10.  If you want to add Silverlight 3 development to your VS10 environment, you can follow my previous post instructions, which basically is to install the SL3 SDK and SL3 developer runtime.  At this time, VS10 will only target Silverlight 3 beta and will also not run the .NET RIA Services bits that you might be using.

What about Blend and Visual Studio 2010 Beta 1?

With VS10 there are some caveats.  With VS10 you can create multi-target solutions.  You can see this when you create a new project in VS10:

Visual Studio 10 multi-targeting

Now for the caveat.  If you select .NET Framework 4 in VS10, and then open your project in Blend 2 you will see this warning:

Blend warning on opening VS10 solution file

In my experience under simple circumstances you can still open it and work with files.  Here’s where beta life starts getting confusing.  If your Silverlight application is just the application, you will see the above warnings and should be able to edit (regardless of if your target in the new project window was .NET Framework 4 or 3.5).  Now, if you also added a web project to your solution and open it in Blend 3 Preview, you will see this:

Blend warning on opening up .NET 4 project

Indicating that the web project type is not supported at this time in Blend 3.  The solution will open in blend (if you say yes) but your web project will have a “?” next to it and read (unsupported project).  You’ll still be able to edit the Silverlight application, but not do anything with the web project.

What about WPF projects then?!

If your target selection was .NET Framework 3.5 then you’ll still get the first warning, but should be able to work with the project.  If your target selection was .NET Framework 4, then you’ll get the unsupported warning and won’t be able to work with this.  Oddly enough, Blend 2 will open the .NET 4 project, weird.  In either route, when you compile in blend you’ll see this note:

   1: Project file contains ToolsVersion="4.0", which is not supported by this version of MSBuild.  
   2: Treating the project as if it had ToolsVersion="3.5".

That should tell you something if you think Blend 2 is going to build your .NET 4 project just because it will open :-).

Why is it this way and when will it all work?

Ah, the magic crystal ball.  If we could get all the teams on the same ship cycle it would be easy, but it just isn’t that way right now.  Basically VS10 went into beta 1 lockdown before certain things for Silverlight and Blend tools were able to hit certain milestones.  So given that, here’s where we stand.

NOTE: Expression Encoder outputs either Silverlight 1.0 or Silverlight 2 templates and the output are completed projects.  If you open up the source for an Encoder project it will prompt the VS10 upgrade wizard, or in VS2008 just open for you to edit (assuming you have the Silverlight tools installed)

For Blend 3 and VS10 projects to work in harmony, an update to the Expression Blend 3 preview that supports Visual Studio 2010 and .NET Framework 4 projects is expected to be available in Q3 of 2009.

For VS10 and Silverlight 3 RTW/.NET RIA Services working, we’re looking at an update to VS10 would be needed and we haven’t determined a timeframe on that just yet.

What should I do?

Well, as a Silverlight developer, I’ve given my opinion already.  Until that update for VS10 happens to enable Silverlight 3 RTW and .NET RIA Services development, I think the best option will still be the released tools for the environment (VS2008, Blend 3).  Consider VS10 something to look at, but not ready just yet for full Silverlight 3 development.

For other project types like ASP.NET, WPF, WinForms, etc. you’ll still be able to multi-target in VS10 and most of these are released right now so you should be in a decent environment.  WPF caveats above still apply as most WPF developers also rely on Blend as a tool for their projects.

Summary

I know this is totally confusing and it sucks.  After re-reading this, my own head spins.  It is easy for us to say it is the pain of an early adopter…and it is.  By sitting on the edge with beta technologies we take risks and have to determine our own rewards.  Knowing this information should help you be informed about your projects.

  • Silverlight 2 + VS2008 + Blend 2 development: released, available, working
  • Silverlight 2 + VS10 + Blend 2 development: available, working (VS10 in beta)
  • Silverlight 3 + VS2008 + Blend 3 development: available, working (Silverlight 3 and Blend 3 in beta)
  • Silverlight 3 + VS10 + Blend 3 development: available, working with caveats (Silverlight 3 beta only, no RIA services)
  • WPF + VS10 + Blend 3 development: available, caveat of Blend 3 will not open .NET 4 projects from VS10

Remember, virtual machines can be your friend!  For some more general Visual Studio 2010 and .NET 4 training information check out the training kit here.  For information regarding ASP.NET MVC and VS10, check out Phil’s post.  Hope this helps!

| Comments

Well today was the public release of Visual Studio 2010 Beta 1.  It is the first time developers will have the chance to take it for a spin and kick the tires.  I wanted to share some information specific for Silverlight developers with regard to Visual Studio 2010 Beta 1.

Visual Studio 2010 is the first IDE that will support two key features for Silverlight developers: multi-targeted Silverlight development and editable design surface for Silverlight.  The second point also comes with things you might expect (like data binding wizards and dialogs as well – I’m lumping all of that in to ‘editable design surface’).  To get started there are a few things you should know.

First, if you are installing from a “clean” environment (perhaps a virtual machine, etc.) and want the multi-target support, here’s what you’ll do:

  1. Install Visual Studio 2010 Beta 1
  2. Install Silverlight 2 SDK (if you attempt to run the Silverlight 2 tools installer it will fail with an error message…just install the SDK).
  3. Install Silverlight 3 Beta SDK (again, don’t attempt the tools installer as it will fail)
  4. Install Silverlight 3 Beta Developer Runtime

Once you have done this, you now have a Silverlight 2 and 3 development machine for Visual Studio 2010 Beta 1.  Congratulations!

Hey, where’s my multi-targeting?!

Be patient.  When you create a new project you’ll see just the standard Silverlight application templates.  Select that first and then you will see the multi-target option in the next dialog:

Visual Studio 2010 Silverlight multi-targeting

Once you select this option you will be starting development using that runtime version.  So remember, it is after you select a Silverlight project type.  If you want to change the target version runtime after you’ve created a project, just right-click on the Silverlight project, choose the properties and you’ll see Target Silverlight Version and can change it there.

What about the editable design surface?

Once you have a Silverlight project ready, you can use the design surface for editing and dragging/dropping UI elements, arranging layout, etc.:

You can also now select items on the design surface and manipulate binding or other properties in the ‘normal’ Visual Studio way (property panes, dialogs).

Hey, what happened to my Silverlight Templates…and what about .NET RIA Services?!

For right now in Visual Studio 2010 Beta 1, the Silverlight Navigation Application template is not available as a part of the SDK installer (it’s actually a part of the tools installer…which you can’t run for VS2010 Beta 1).  If you want that template, just export one from Visual Studio 2008 and import it into this environment.  It will then show up under the My Templates section.

.NET RIA Services also will not install for VS2010 Beta 1 right now.  So if you want to play around with those bits, stick to VS2008 SP1.

Both of these are known and will be resolved in the future.  Hopefully you understand that the products are in varying beta stages (VS2010, Silverlight 3 and RIA Services) and are not in sync right now.  Kind of a pain, but it’s the sting of early adoption I suppose.

My Recommendation

So what should you do?  Well I do think you should try Visual Studio 2010 and play around with it.  If you need RIA Services development, then stick with Visual Studio 2008.  If you have the ability to run a second machine or a virtual machine, I recommend putting Visual Studio 2010 in that environment.  For Silverlight 3 we will be targeting VS2008 SP1 for release.  Obviously the team is working on supporting VS2010, but for beta 1, we just couldn’t get it in time.  So I’d personally recommend sticking with VS2008 as your primary dev environment for all Silverlight 3 goodness…and run VS2010 in a separate space to play around with. 

Hope this helps!