| Comments

Recently our team released a service release for Silverlight on 1-Sep-2010.  We affectionately call these “GDR” releases (general distribution release).

NOTE: Other teams have different names for different things.  I’m not sure why Microsoft doesn’t have a standard on these things and it’s funny to hear marketing teams argue the benefit of one name over the other.  For what it is worth, in my eyes, if it isn’t a major milestone release (or at least a ‘dot’ release [4.0->4.1 for example] then it is a service update.  Call it a GDR, Wave X, Service Pack, R2, blah blah.

In the GDR1 release (version 4.0.50826.0) we also released an update to the SDK.  This is where it can start get confusing…allow me to attempt to explain.  GDR1 released:

  • Runtime
  • SDK

On top of that when the release of the Windows Phone Developer Tools released, they shipped the GDR1 bits (and SDK) with them…so while there was no real “tool” update (outside of the required updates for WP7), them shipping the update in the tools effectively put all the new bits on your machine if you installed it.  Most of the time GDR releases are runtime-only releases.  Putting out an SDK release can have some consequences (beneficial if you need the update) as some of you have seen.

The Problem

Here’s what people are seeing…

Hey my users are getting messages to upgrade their Silverlight runtime when my app says minRuntimeVersion=”4.0.50401.0” – what gives?!  I thought this thing was supposed to work!?!?

Every time someone asks me about this, my first question is if they’ve installed the updated SDK.  Almost all the time the answer is yes.  And that is where the issue is (as also they’ve recompiled their app).  Along with the minRuntimeVersion, within the XAP the AppManifest.xml file there is also a RuntimeVersion attribute stamped for the app.  Both of these versions are being set by the version of the SDK.  So when you install a new SDK, that version is the value used here.

NOTE: Your <object> tag minRuntimeVersion isn’t updated on existing projects, but check on a new project and you’ll see it updated there.

So even though you might have specified in the <object> tag minRuntimeVersion for RTW (4.0.50401.0), the fact that the XAP is demanding (via the AppManifest) a later version is what is causing the conflict.

The problem exists when you either want (or have no choice because of auto-updates you subscribe to) the latest Silverlight runtime but as a developer, need to maintain applications and do not want to drive the user to an upgrade to the latest bits.

The Solution

If you find yourself in this situation and don’t want to keep manually changing the AppManifest attribute after each build and re-packaging the XAP, then you can do one thing to keep your environment the way you expect it.

To be clear, what I am outlining here will: enable you to have the latest Silverlight runtime while still building against the RTW of Silverlight 4.

First, you can uninstall Silverlight 4 GDR1 SDK (you can do this via the Add/Remove Control Panel).  Once you’ve done that you can install the Silverlight 4 RTW SDK (4.0.50401.0).

Now you’re done :-).  If you have apps that have been in this problematic state you’ll likely have to do some cleans on your build to ensure that the AppManifest is overridden correctly now.

Future Updates

As I mentioned, generally speaking the GDRs are runtime-only releases.  And actually we issued a second service release in September (GDR2 – 4.0.50917.0). 

NOTE: This GDR2 update has NO OTHER fixes than the issue mentioned in the KB article.  This was fixing a regression that prevented an app from loading/updating.  No other fixes are in this build at this time.

In these cases as a developer all you need to do is ensure you have the latest developer runtime to ensure you can debug, etc.  The Windows developer runtime can be obtained here.


If you’re in the situation as described above where your users are seeing a prompt that is not expected, you can easily modify your dev environment to prevent this.  The simple summary is:

  • Keep up-to-date on the latest developer runtime
  • Have the RTW SDK installed

The consequences here are if you are doing development with LightSwitch (which requires the updated SDK).

I’m not sure if my rambling here helps, but I tried to just say it how it is.

Hope this helps!

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

| Comments

Today we released an update to Silverlight 4 (update build is 4.0.50826.0) along with an updated SDK.  We appreciate our customers’ patience on working with us to help identify and verify necessary updates to this service release.  You can find all the details in KB2164913.  Here are the relevant highlights:

  • SDK feature to enable Add New Row capabilities in DataGrid control
  • Improving startup performance of Silverlight applications
  • Adding mouse wheel support for out-of-browser applications on the Mac platform
  • Various media-related fixes around DRM content
  • Fixed memory leak when MouseCapture is used
  • Fixed memory leak for DataTemplate usage

All the installer links have been updated to leverage these new bits for our customers.

For end users

For end users, having them simply install the runtime will provide them with the updated bits and benefits of the fixes/features in this service release.  The best way to force encourage your users to upgrade to this service release would be to leverage the MinRuntimeVersion attribute of your object tag:

   1: <object data="data:application/x-silverlight-2," type="application/x-silverlight-2"
   2:     width="640" height="400">
   3:     <param name="source" value="YOUR_PATH_TO_XAP" />
   4:     <param name="background" value="white" />
   5:     <param name="minRuntimeVersion" value="4.0.50826.0" />
   6:     <param name="autoUpgrade" value="true" />
   7:     <a href="http://go.microsoft.com/fwlink/?LinkID=149156&amp;v=4.0.50826.0" style="text-decoration: none">
   8:         <img src="http://go.microsoft.com/fwlink/?LinkId=161376" alt="Get Microsoft Silverlight"
   9:             style="border-style: none" />
  10:     </a>
  11: </object>

Notice lines 5 and 6 above.  This would trigger that the end user is required for your application to run and require them to upgrade. The minRuntimeVersion/autoUpgrade are the minimum to require your user to upgrade to the later version.  Ideally you would follow good installation experience guidance (see “Installation Experience Whitepaper” with complete sample source code) to customize your install and/or upgrade experience.

For Developers

If you are a developer and authoring Silverlight applications you may want to grab the new developer bits and updated SDK:

I would install the developer build first and then the SDK and you’ll have a refreshed environment.  As with any release we try to get you the information as soon as possible and sometimes the information flows faster than the download servers replicate.  If you aren’t getting the updated bits using the links above, please be patient as the download servers from Microsoft refresh their replication caches. 

Note that when you now create a new project you’ll be using the new SDK and so the minRuntimeVersion (see above) of the project templates as well as compiled bits for your SL4 application will be using/requiring the updated runtime.

There are NO Visual Studio tools updates for this release so the Silverlight4_Tools.exe package is not needed to re-install.

For Visual Studio LightSwitch Users

When Visual Studio LightSwitch shipped they included a pre-release later build of Silverlight 4.  This caused some issues for customers who were using a single machine to evaluate LightSwitch but also using the same machine.  Any Silverlight 4 application developed and deployed would give customers messages indicating that they needed a later version of Silverlight, but were unable to acquire a compatible version!

This is now solved with this service release.  Simply put: If you are using LightSwitch, install the updated developer runtime and SDK.  This will solve this issue and allow you to develop LightSwitch applications as well as production Silverlight 4 applications.

Hope this helps!  As always if you have feedback on Silverlight, here are some methods of providing feedback to our team.