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:

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:

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.

One of the new features I mentioned in my What’s new/changed post on Silverlight 3 is the fact that any application developer can take advantage of the cached assembly functionality provided by Silverlight.  Let me show you how and start with the current situation.

Current Situation with Silverlight assembly references

If you are building a Silverlight application, chances are you are referencing assemblies either from the SDK, Silverlight Toolkit or other great Silverlight third party controls/frameworks.  When you Add Reference to these controls/frameworks, their assembly is copied to your application and packaged up in your XAP.  For some situations this is fine and you have no reason to care at all…it just works.  When you look at the AppManifest.xml file for your application you’ll notice the AssemblyPart nodes for each referenced assembly not in the core – and these are in your packaged XAP file.  Take a look at my sample application which has a reference to a simple 3rd party assembly: TimHeuer.SimpleFunctions.dll:

   1: <Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment" 

   2:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" EntryPointAssembly="SilverlightApplication1" 

   3:     EntryPointType="SilverlightApplication1.App" RuntimeVersion="3.0.40624.0">

   4:   <Deployment.Parts>

   5:     <AssemblyPart x:Name="SilverlightApplication1" Source="SilverlightApplication1.dll" />

   6:     <AssemblyPart x:Name="TimHeuer.SimpleFunctions" Source="TimHeuer.SimpleFunctions.dll" />

   7:   </Deployment.Parts>

   8: </Deployment>

You can see that my custom assembly is included in the manifest as a separate AssemblyPart entry.  Looking at the XAP package contents you’ll also see it there:

This is how we’ve been building Silverlight applications since Silverlight classic…um…I mean, Silverlight 2.  All of this will still work and if you do nothing, then no worries.

Introducing Application Library Caching (or External Assembly Parts)

In Silverlight 3 beta we introduced this feature to reduce the initial XAP package size of your application by providing external assembly parts for certain Microsoft components and controls.  In beta, it was a feature only reserved for Microsoft-delivered assemblies.  Now that we’ve released, we’ve opened this feature to any developer wishing to take advantage of it. 

What does it do?  Let’s take a look at perhaps a common referenced assembly: DataGrid.  When you add this assembly to your application, your XAP package will increase in size because it is not a part of the core (mine went from 4K to 204K because DataGrid also brings some other assemblies with it).  In Visual Studio, take a look at the properties dialog for your Silverlight application and you’ll notice a new checkbox:

By clicking this checkbox you are telling Visual Studio to make sure that any assembly that offers this feature, to not package it in your XAP but to reference it as an external assembly part.  The result is two-fold: your manifest changes and your XAP no longer includes this assembly.  Take a look at what happened to my sample application’s AppManifest.xml when I enabled that feature:

   1: <Deployment --attributes removed for formatting only-->

   2:   <Deployment.Parts>

   3:     <AssemblyPart x:Name="SilverlightApplication1" Source="SilverlightApplication1.dll" />

   4:   </Deployment.Parts>

   5:   <Deployment.ExternalParts>

   6:     <ExtensionPart Source="TimHeuer.SimpleFunctions.zip" />

   7:   </Deployment.ExternalParts>

   8: </Deployment>

Notice the new node ExternalParts?  There’s no reference to my TimHeuer.SimpleFunctions.dll but there is one to a TimHeuer.SimpleFunctions.zip file as an ExtensionPart.  This is because my assembly has chosen to opt-in to enabling this feature if the developer wants to use it in their application deployment.  My XAP file also reduced from 6K to 4K in size (note: in my DataGrid example you’d see a reduction of approximately 200K).  Using this feature, when users visit your web application, the application and package are downloaded.  These files are added to the browser cache so they can be used on subsequent requests.

How is this accomplished?

So what’s going on here?  It’s actually quite simple and there are two ways you can do it as an assembly author (well, really one way, but two methods of how to provide your assembly deployment).  First, you have to make sure that your assembly has a strong-name key.  This is probably good practice anyways for your development team.  This gives you a public key token which you’ll need for this feature.

The next thing you have to do is provide the external part manifest for your assembly.  This is a simple XML file that does not have to be included *in* your assembly, but needs to exist in the same physical place as your assembly (i.e., right next to it in the file system).  This file must also be named <AssemblyFileName>.extmap.xml.  As an example in my sample, my custom assembly is TimHeuer.SimpleFunctions.dll and my file will be TimHeuer.SimpleFunctions.extmap.xml.  The contents of the file is simple and here is mine for this sample:

   1: <?xml version="1.0"?>

   2: <manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

   3:           xmlns:xsd="http://www.w3.org/2001/XMLSchema">

   4:  

   5:     <assembly>

   6:         <name>TimHeuer.SimpleFunctions</name>

   7:         <version>1.0.0.0</version>

   8:         <publickeytoken>f265933def965411</publickeytoken>

   9:         <relpath>TimHeuer.SimpleFunctions.dll</relpath>

  10:         <extension downloadUri="TimHeuer.SimpleFunctions.zip" />

  11:     </assembly>

  12:  

  13:  

  14: </manifest>

Taking a look at this manifest, let me point out some important things.  The obvios of the assembly short name and version are there.  The publickeytoken node must be there as well.

NOTE: How do you obtain your public key token from a signed assembly?  Man I wish there was a tool in VS (plugin maybe) that made this simple.  But just get to the Visual Studio command prompt and execute: sn.exe –T <path-to-assembly>

Notice the next two nodes: relpath and extension.  The relpath node is the name of your assembly file.  The extension node indicates where to get the package for the assembly part.  Here’s where it might help to explain the options.  First, the endpoint to the extension part will be a ZIP file.  Within that file can exist your assemblies.  Take a look at the downloadUri attribute.  This tells the Silverlight application where it is going to get the zip file.  If you just specify a file name like the above two things will happen.  Your external part will be packaged into the ZIP file name you provide here and then that zip will be deployed alongside your XAP file (not in, but alongside it like in the ClientBin directory).  This means that wherever your XAP is, so does this ZIP need to reside.  After compiling your application you’d see it in your web applications folders like my sample here:

You can, however, provide a URI to the file.  Let’s look at a modification of the above:

   1: <?xml version="1.0"?>

   2: <manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

   3:           xmlns:xsd="http://www.w3.org/2001/XMLSchema">

   4:     <assembly>

   5:         <name>TimHeuer.SimpleFunctions</name>

   6:         <version>1.0.0.0</version>

   7:         <publickeytoken>f265933def965411</publickeytoken>

   8:         <relpath>TimHeuer.SimpleFunctions.dll</relpath>

   9:         <extension downloadUri="http://timheuer.com/asmcache/1.0/TimHeuer.SimpleFunctions.zip" />

  10:     </assembly>

  11: </manifest>

Notice the different downloadUri attribute.  This is a unique URI that must be accessible by the Silverlight application (i.e., don’t put an Intranet URI here if you are using this feature on those bigger web tubes).  The resulting AppManifest.xml now looks like this:

   1: <Deployment --removed attributes for readibility-->

   2:   <Deployment.Parts>

   3:     <AssemblyPart x:Name="SilverlightApplication1" Source="SilverlightApplication1.dll" />

   4:   </Deployment.Parts>

   5:   <Deployment.ExternalParts>

   6:     <ExtensionPart Source="http://timheuer.com/asmcache/TimHeuer.SimpleFunctions.zip" />

   7:   </Deployment.ExternalParts>

   8: </Deployment>

And notice my project no longer has a local ZIP file in the ClientBin alongside my XAP:

This now tells Silverlight that it will need to get this assembly extension from this remote location.  This operation is done asynchronously by the runtime and you don’t have to add any additional code to request it.  Basically if your downloadUri is a file name, the build system packages the assembly into a zip file and deploys it alongside your XAP file.  If the attribute is an absolute URI, you are then responsible for providing the ZIP yourself and will need to ensure it is packaged and in that URI location point.

Why would you use this?

You may be asking yourself why or when you’d want to use this feature.  After all, in the end, the assembly will still be downloaded.  So whether or not it is in your initial XAP or later in a ZIP assembly request, the bits will still get to the end-user.  So why?

I can think of two initial scenarios where you’d want to consider this.  If you are a component vendor and want to provide a location for your consumers to get your bits, you could do this.  This may help manage a central location of known versions and enables the application developer to get the bits from the source rather than have to deploy them to their servers.  The second scenario I can think of is one of enterprise common assemblies.  If your team develops common components that all applications should use, then you can provide a central location to deliver these from and ensure people are using the correct bits/versions.

Things to look out for

As with any new feature, I’m sure you may be skeptical…and perhaps somewhat confused (if so, I apologize).  One of the obvious things to look out for in this feature is that if you rely on those referenced assemblies and you aren’t packaging them in your XAP or aren’t deploying them from your own servers, you are depending on that remote location to deliver them.  The natural concerns about latency, uptime, firewalls, etc. come into play here so be sure to understand your architecture choices correctly.

If you are using an absolute URI for the downloadURI attribute, there are two things you should consider.  First, if it is going to be delivered from a different domain than the XAP file, then a valid cross-domain policy file must exist at the domain serving the assembly package (zip).  Second, treat the absolute URI as a unique identifier.  Version should be unique as well.  Consider a URI naming scheme along the lines perhaps of something like this:

   1: http://timheuer.com/asmcache/1.0/TimHeuer.SimpleFunctions.zip

This way each version of the assembly library cache is unique.

If you have checked that “reduce XAP size…” checkbox and then try to also check the out-of-browser settings, you’ll be greeted with:

Unfortunately right now the assembly caching feature is not available in out-of-browser experiences.

Summary

The assembly caching feature is a cool feature to be able to take advantage of when your architecture makes sense to leverage it.  It isn’t going to be for everyone, but that’s what makes it great – it is an opt-in feature for you as the assembly developer as well as the consumer.  With a few simple steps you can take your Silverlight assembly and prepare it for use on this feature as described above.  What do you think of assembly caching?

At last, Silverlight 3 is released!  It has been a long road…wait a minute, actually it’s only been 8 months since the last release!  Whoa, that’s some wicked supersonic Microsoft time there!  Anyhow, we are finally released.  A while back I wrote a post on What’s New in Silverlight 3 and it still all applies.  I’d encourage you to read that post as well.  There are, of course, some subtle changes in a few things from an implementation side of things, but those are all documented in the release.

Here’s where you go to get the exhaustive goods.  First if you don’t have Visual Studio or Silverlight yet installed and want to try it out, give the Web Platform Installer a try.  In one click we’ll install everything for you!  The image link here will install VS2008 Express (free) and the Silverlight 3 developer tools:

Here’s some links to all the other bits if you so desire:

• Visual Studio Tools for Silverlight 3 (if you already have Visual Studio 2008 SP1 installed)
• Silverlight Toolkit (with Ms-PL licensed source code)
• Developer runtimes: Windows and Mac platforms (note if you install the dev tools you already have this)
• End User Runtime (all supported platforms) for your users and for your apps to prompt to install.
• Offline CHM Documentation
• Changes Documentation (including breaking changes from SL3 beta and quirks mode items for SL2)
• Expression Blend 3 Release Candidate (which targets the release version of Silverlight 3)
• .NET RIA Services July 2009 release (check out cool info about this release below)
• Deep Zoom Composer Release Candidate

That should give you the totality of information to get as deep as you want with all the features.

NOTE: If you are behind a firewall and get an error installing the VS tools, you may be running into a common issue with those ‘behind the walls’ with downloading the runtime.  Basically download the tools, then download the *developer* runtime (link above) and follow the offline instructions here (this was a post from earlier days but still applies).

While you are downloading the bits, take a look at some thoughts on new/changes below here.

What’s changed/new since beta?

There are a few things that are finally in the bits that we’ve talked about since beta but probably not many have seen or been able to work with.  Here’s some of my highlights:

Improved text rendering.  The team made large investments in improving the overall rendering of text in Silverlight applications.  Improved text rendering is available to all supported platforms.  Improvements for text animation have also been introduced.

Updated Out-of-browser tooling.  In the beta, the manifest had to be written by hand for taking your Silverlight application out-of-browser.  The Visual Studio tools now have a user interface for helping you do that.  When you look at the properties dialog of a Silverlight application you’ll now see the checkbox to enable these settings:

and the resulting tooling to create the file for you:

The result is that an OutOfBrowserSettings.xml file is created and your .*proj file is decorated with some build instructions on how to compile that for the manifest.  If you have existing projects with the older settings in the manifest, it should be a quick and easy change, but I had also created a quick tool that was helping me do these in bulk.  You are welcome to use my OOBChanger ClickOnce app.  You basically point it at the folder where your Silverlight .**proj file is located and it does the work.  This is certified works on my machine utility, but I wanted to pass it along in case you had a lot to do.

NOTE: Remember to DELETE THE OLD AppManfiest settings (Deployment.Identity) or your application WILL NOT RUN.

In addition to the tooling change, almost all the Out-of-browser APIs got name changes.  For instance, instead of .Detach() it is now .Install().  Also the out-of-browser update model I’ve previously talked about has change slightly.  There is now an API called CheckAndDownloadUpdateAsync() which triggers the update check.  Once called, if an update is available, it is being downloaded asynchronously to the user.  There is an event you can subscribe to for the completion of this event to check if an update did indeed occur and alert the user.  The change here effectively is that you, the developer, now perform when you want that update check/download to occur.

Where did my design view go?!  You may notice right away that the VS tools no longer have the preview mode for your XAML in Silverlight projects.  This is by design.  We heard some pretty vocal feedback that the preview was usually turned off for most development because it was not turning out to be helpful as the applications got more complex.  The team decided put the resource investment into creating a great editable design surface in VS2010 instead and not delay the release of Silverlight 3.

ASP.NET Server Controls.  In the Silverlight 2 SDK and the Silverlight 3 beta, we had two ASP.NET server controls: asp:Silverlight and asp:Media.  These were both controls that served as wrappers to emitting the <object> tag or other JavaScript to instantiate a Silverlight object.  The <object> method is more flexible for developers on various platforms and we have decided not to include updates to these controls for Silverlight 3 SDK.  People may ask how they are going to emit params, etc. using server code, and that is still entirely possible.  We have a whitepaper talking about various methods of doing that including the simplest ones like this:

   1: <object type="application/x-silverlight-2" ...>

   2:   <param name="Source" value='<asp:Literal id="Source" runat="server"/>' />

   3: </object>

That whitepaper about the ASP.NET Server Controls can be downloaded from the Silverlight whitepapers site and includes some guidance, known issues, and things to be aware of if you are still using those controls and move to Silverlight 3.  It also includes a link to where you can get the source code for those controls if you want to extend them yourself.

Silverlight.JS updates.  Just a minor update that we compressed the bits so that if you want to use them it is a 7K library instead of a 57K library.  The “debug” (human readable) version will be available for you to download if needed at the Silverlight.js code site and is licensed under Ms-PL.

New networking stack.  What?!  That’s right a new networking stack option is being introduced for Silverlight 3 and is new since beta.  Silverlight has always leveraged the browser HTTP stack and will continue if you don’t care.  In Silverlight 3 we’ve introduced the Client HTTP stack as an option as well.  You must opt-in to use the client HTTP handling.  This gives you the ability to go more than just GET/POST (i.e., more REST-ful verbs), using response status codes/headers, etc.  You can opt-in to use the client HTTP stack on all requests, requests for a specific domain, or on a per-request basis like this:

   1: HttpWebRequest request = (HttpWebRequest)WebRequestCreator.ClientHttp.Create(new Uri(

   2:         http://api.search.live.net/qson.aspx?query=Silverlight));

Hopefully this new client stack will give you some flexibility in some situations beyond what the browser networking stack was providing.  We continue to look for feedback on improving this area.

Assembly Caching.  This feature was in the beta, but was only limited to Microsoft specific assemblies and only a few.  In the release we’re making this option available to all developers.  This gives you the ability to host your satellite assemblies and not have them packaged as a part of the initial XAP payload.  They will then be download asynchronously when needed.  This feature is great for shared assemblies in corporations as well as component vendors.

Where did DataForm go? DataForm was moved out of the SDK and moved into the Silverlight Toolkit release mechanism.  It is still available in its full awesomeness of glory, but just in a different place under System.Windows.Controls.Data.DataForm.Toolkit namespace.  Look for it (and the source!) in the Silverlight Toolkit downloads.  There were some changes here including the removal of the DataFormFields (like DataFormTextField) in favor of using the primitives more.  So instead of:

   1: <datacontrols:DataFormTextField Text="{Binding Path=FirstName}" />

you’d use

   1: <datacontrols:DataField>

   2:     <TextBox Text="{Binding Path=FirstName}" />

   3: </datacontrols:DataField>

We felt this is a more flexible model for growth in the long run for DataForm usage.

Navigation framework updates.  The navigation framework got some updates including how you use the UriMapper concepts.  In the beta you had to have it as a resource and the resource key had to be named ‘uriMapper' or it wouldn’t work.  We’ve changed that so now you can still have your mappings as a resource, and can reference them on your Frame like this:

   1: <navigation:Frame UriMapper="{StaticResource MyFooMapper}">

   2: ...

   3: </navigation:Frame>

or you can explicitly write them on the Frame itself

   1: <navigation:Frame x:Name="MyCoolFrameNav">

   2:     <navigation:Frame.UriMapper>

   3:         <nav:UriMapper>

   4:         ...

   5:         </nav:UriMapper>

   6:     </navigation:Frame.UriMapper>

   7: </navigation:Frame>

Hopefully that makes things a little more flexible for you.  Also be sure to check out the additional 7 free navigation application template themes we’re providing for you.

.NET RIA Services.  The July 2009 update for .NET RIA Services is now available for you to download as well.  We’ll be posting some deeper tutorials on how to use RIA Services with Silveright.  When you download the bits, there is a walkthrough document that helps you get a good overview of the framework.  Best of all, the July 2009 bits come with a Go-Live license!  Sweet!  Now you can get rolling on some deployment using RIA Services!  Be sure to use the .NET RIA Services forums as the team is very active there!

Browser Zoom.  Silverlight applications now respond to browser zoom requests.  So if you’re viewing an app in IE you can go down to that little right corner and change the zoom to 200% and see the wonder of the ClearType text rendering :-).

Silverlight 2 changes and quirks mode.  In my previous post where I asked you all to make sure your SL2 apps ran fine under the beta, there was a lot of questions about what this quirks mode list of changes was going to be.  At the time we hadn’t formalized the document so I couldn’t share it and I didn’t want to share something incomplete.  The changes are now outlined in the Silverlight 3 changes documentation (section 5).  There are some changes that may directly affect you (like OpenFileDialog requiring a user-initiated action) and some that you won’t care about.  The key here to remember is that even if you have this code in your SL2 application, as long as it is compiled in SL2, it will ran fine in Silverlight 3 because of our quirks mode.  If you compile in Silverlight 3, however, you will be playing by SL3 rules, so pay attention if these affect you.

What’s the deal with Blend?  Expression Blend 3 is releasing a Release Candidate (RC) build alongside the Silverlight 3 final release.  Expression Blend is a part of the overall version 3 suite for Expression which is not yet released (which includes Expression Encoder 3 as well).  The RC build was designed to ensure you can target SL3 applications.  It also includes the feature everyone is talking about: SketchFlow.  Be sure to check out the RC build and play around with it…there are some great improvements.

Encoding media for Silverlight.  IIS Smooth Streaming has already been released and you can play around with it since Silverlight 2 applications.  Expression Encoder 3 features were recently announced (including screen capture!) one of which indicated that updated media templates will be provided.  Here’s a preview of some of my favorites:

‘Expression’ theme: simple, but super elegant.  Has built-in pop-out control, cover-flow style chapter/playlist viewing and offline mode support.  Wicked.  Makes me scared about my project with Joel.

‘Jukebox’ for audio playback

The source code for these templates are provided as well so you can extend and further template to your liking.  The IIS Smooth Streaming encoding capabilities are also built into the product so you can produce your own smooth streaming bits to put on your IIS7 server.

Summary

I’m sure I’m missing some things, but there is all goodness in the Silverlight 3 release.  You just have to experience it yourself :-).  Go ahead and Get Started now!  The marketing team has also updated their site at http://www.microsoft.com/silverlight with some updated case studies and additional information for you to help learn how Silverlight can empower your developers and help you create unique experiences on the web.

Hope this helps!

With the Silverlight 3 Tools for Visual Studio, developers get access to the Silverlight Navigation Application template.  By default the styles (which are located in the project’s Assets/Styles.xaml file) are really good and neutral for the application layout.  Now, keep in mind this is an overall application layout style and not control styles/templates.

In addition to the default look provided by the tools out of the box with Silverlight 3, we’re providing 7 additional application template themes for you to enjoy, extend, whatever.  Corrina and team had developed these for the community to consume and we’ve put them up on the Expression Community Gallery for download.  Here’s a preview with the links to each template:

Aurora (also available for RIA Services Template):

Frosted Cinnamon Toast (also available for RIA Services Template):

Lime Shocker (also available for RIA Services Template):

Pinky (also available for RIA Services Template):

Retro:

Skyline:

Subdued:

There you go, we hope you enjoy them.  Download the zip file and you will see a Styles.xaml file included.  Simply put this in the applications Assets folder, replacing the default and you will automatically have the new theme in your application.

Hope this helps!

UPDATE: FloatableWindow is now on CodePlex for easier community contributions and management of latest source and builds.  FloatableWindow CodePlex Project. If you like this idea VOTE FOR IT in the Silverlight Toolkit!

A while back I wrote a post where I refactored the Silverlight ChildWindow to create a non-modal window and I called it FloatableWindow (you can see why I’m not a good marketer…hey I could have called it Microsoft Silverlight ChildWindow Refactored Edition Express).  A few folks found it useful, for which I’m appreciative of the comments.

My buddy Karl Shifflett decided to use it in Glimpse as the diagnostic window – thanks Karl!  Karl even added some code to it to basically provide a start position (HorizontalOffset and VerticalOffset).  Another request Karl had was to add resizing capabilities to the window.

I’m pleased to say that I added both of these features to the source.  I modified Karl’s offset properties a bit to not only include them in the Show() override, but also as public properties that would be used if available.  For resizing, I added a ResizeMode property which matches the System.Window.ResizeMode enumeration.  I chose to use that enumeration for some consistency with WPF APIs, but frankly it really only supports CanResize and NoResize with the default being CanResize.  You can see an example of the resizing capabilities here in this animation:

As you can see (sorry for the horrible animated image but just wanted to make it simple), the resizing handle will appear in the lower right corner of the window.

UPDATE: Based on Laurent/yaip’s feedback I reverted back to my original design, here’s the mouse out (normal) and mouse over states for the handle:

  I chose to make it invisible unless someone moves their mouse into that position.  Is that the wrong UX do you think?  I know it isn’t entirely consistent with something like WinForms, but I wanted to be a little different. 

Additionally I wanted to use the SizeNWSE Cursor as a normal WPF/WinForm window would use, but unfortunately that’s not a valid Cursor for Silverlight right now.

I did try to make the resizing adorner a template part so you could make it something else (right now it is just a path).  I haven’t really tried messing with it that much though.

I think my math might be a bit off in some scenarios and I’m still frustrated with the Popup and ZIndex issue in Silverlight, but I know there is an open issue for Silverlight to look at this so I’m trying to stay calm about it.  Anyhow, some subtle adds to make it hopefully just a bit more useful for anyone who cares (or cares to learn from it).

You can download the source code here: FloatableWindow_1.3.zip

Hope this helps and I appreciate any comments regarding the update or if you see issues in your scenarios.