×

First time here?

You are looking at the most recent posts. You may also want to check out older archives. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS or email. Thank you for visiting!

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.

Summary

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.


9/29/2010 12:58 AM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
Ok, Really kinda confused now,

Up until your post today, I was aware that there were two minor releases (GDRs?) for Silverlight 4, namely theses:

http://support.microsoft.com/kb/982926 - 3rd June (DRM fixes etc)
http://support.microsoft.com/kb/2164913 - 1 Sept (Data template leak etc)

but in your post above, you mention the June release as GDR1 and this a new Sept 28th release which I haven't heard anything about at all about as GDR2: what happened to the 1st Sept release? Is this not a GDR? If so, what is it?

Just getting a bit confused! Otherwise, nice post! :)

Thanks,

Andy.
9/29/2010 1:52 AM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
How can I get the last version(4.0.50917.0) of Silverlight.exe & Silverlight_Developer.exe? And Mac Runtime?
9/29/2010 1:55 AM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
Thanks for the warning, I was about to make a release with the minruntimeversion too high..

As an alternative to the solution above: uncheck the 'generate SL manifest' projectsetting. Then take a previously generated AppManifest.xaml, change the minruntimeversion to 4.0.50401.0, and add it as a content file to your project. Of course now you have to maintain it manually, but you dont need to switch SDKs.

Cheers,
Casper
9/29/2010 4:35 AM | # What's on Windows Update?
Tim,

Can you please clarify what version of SL we'll see on Windows update -- developer or "regular?" if we have the developer runtime already installed?

Yesterday as I was running updates on a few machines, I saw the new SL bits listed there. I suspect that the developer runtime gets updated with the new developer runtime, as the file sizes on WU were different among the machines where one had the regular runtime and the other had the developer one. The regular one was about 6 megs and the developer machine was about 8.

Can you confirm this? Just want to be sure that we can use WU to update our developer runtimes and not have a regular version put on top of it.

Thanks
9/29/2010 5:01 AM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
Seems the feature isn't a feature anymore.

>>within the XAP the AppManifest.xml file there is also a MinRuntimeVersion >>attribute stamped for the app.
In the manifest, I see only a "RuntimeVersion" attribute. Another confusion?

Why not adding an attribute "RuntimeVersion" and "MinimalRuntimeVersion" to the AppManifest.xaml? So the "RuntimeVersion" is managed by the compiler/SDK and the other configurable by the developer.
9/29/2010 6:34 AM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
Hello Tim can you help me here with two issues:

1) I'm trying to download 4.0.50917.0 both developer and client but the .exe's downloaded say 4.0.50826.0.

2) Where can I get the installer for the "initial 4.0" release? 4.0.50524. I do not want my users to keep updating and updating until a major release so I want to provide them with the installer for the initial 4.0 version.

Thanks.
9/29/2010 7:38 AM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
Thanks Tim! This is great - helps me and I'm sure others quite a bit.
9/29/2010 9:25 AM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
Do you have any suggestions when the required version is newer than what the user has and local policies don't allow users to add plug-ins? This is causing my customer to contact their IT teams just to get the lastest SL version installed.
9/29/2010 6:46 PM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
I have a customer where the computer is not connected to the internet. If, on a different computer without Silverlight, I visit http://www.microsoft.com/getsilverlight download the silverlight.exe the version of the exe is 4.0.50826.0

I run silverlight.exe on the computer and start my app but it just hangs at 100%

I'm now guessing at what is wrong and wondering if the 4.0.50826.0 install still needs to get some updates over the internet. Is there somewhere I can get a full plugin installer to get the computer to 4.0.50917.0 without an internet connection.
Gravatar
9/29/2010 8:03 PM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
How do I determine the version number for the Silverlight developer runtime insalled? Will the developer runtime version 4.0.50917.0 be automatically installed by Windows Update?
9/29/2010 9:43 PM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
The point about using VMs for this is when you have multiple projects, where in 1 project you want to use the latest sdk and another project where you want to stay on RTW, you'd have to constantly unintall/install different versions of the SDK just to build the XAP, or setup different VMs with different versions of the SDK to do separate builds. Not really that ideal..
9/30/2010 5:20 AM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
The Silverlight installer at http://go.microsoft.com/fwlink/?LinkID=149156 seems to return the latest version, even if I add '&v=4.0.50401'.
Did I make a typo, or is there some other place to get the 4.0.50401 runtime?
Some of my customers have that version preinstalled and locked down. So now I need to test what will be worse: shipping my app without the bugfixes in the GDR0+GDR1, or running my app with GDR1 controls on a RTW plugin. Or will that last option simply not run at all?
Casper
10/2/2010 2:39 AM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
Nice try, but this process is just a mess.

I never mind throwing developers under the bus, but this does it to our customers, and that's not good for SL's image, and our business.

There's got to be a better way!
10/3/2010 9:46 PM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
Please have the MSDN documentation updated to mention that the minRuntimeVersion parameter in the HTML is not in full control of this process.
10/21/2010 12:47 PM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
Tim you saved my day. i was struggling with this from past few months. most of my users don't have rights to install the silver light runtime.
11/8/2010 12:19 PM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
If the assembly is stamped with the min runtime version it "demands", of what use is the minruntime version setting on the object tag? In part I am asking saracastically, but in part, I really want to know what the (side)effect is of setting it differently and if is not obvious based on your answer, what is the use case for having it set differently.

Regardless, there should be an easier way (set and forget way) for a developer to have the latest version of the SDK, but not require the deployed app to be a later version ... after all each new version strives to be backward compatible.

Seems like the closes we can get is Casper's suggestion above:

"As an alternative to the solution above: uncheck the 'generate SL manifest' projectsetting. Then take a previously generated AppManifest.xaml, change the minruntimeversion to 4.0.50401.0, and add it as a content file to your project. Of course now you have to maintain it manually, but you dont need to switch SDKs."

2/2/2011 9:29 PM | # re: Understanding Silverlight releases (and the September 2010 2nd service update)
Thank you so much for this article, it helped me like alot and saved my lots of time.

 
Please add 3 and 4 and type the answer here:

DISCLAIMER:

The opinions/content expressed on this blog are provided "ASIS" with no warranties and are my own personal opinions/content (unless otherwise noted) and do not represent my employer's view in any way.