For a Silverlight app compiled and tested base on runtime 2.0, there is a chance that the client upgrade to Silverlight 3.0 (in the future) before my app compiled and tested base on 3.0.
I think the runtime is "generally" backward compatible. But for mission-critical app, is there a way to enforce a Silverlight app to run on a specific version of runtime?
In the Appmanifest.xml, the <version> tag seems not fulfil the requirement.
The minimum version of the Silverlight runtime required to run your Silverlight application. For example, if you set the value of this element to1.0, the user
must have version 1.0 or greater of the Silverlight runtime to view it. If you leave this value blank, the user will be forced to download the latest Silverlight runtime to run your application.
Hi! There is a param you can set when your Silverlight Application is created that will specify a minRuntimeVersion. Just leave it as the default and you should be good to go. If you want to tell the user they have the wrong version, I'd put some sort of image
in the usual Silverlight Error-Area -- the same place where it tells them to "Get Silverlight."
I did study the minRuntimeVersion. That is the minimum Silverlight runtime that your Silverlight app expected to be compatible. But my question is that I cannot assume a newer version of runtime works with my app which is compiled and tested using an older
version of runtime before our own testing. However, I cannot control the version of runtime used on customer's machine.
In other words, the requirement is to enforce a "specific" version, NOT a minumum version.
Oh! Yes, you are correct. I was thinking incorrectly. (I'm sleepy.) At the moment, I do not know of any way to test that. I know there is also the AutoUpgrade property, which is set like the MinRuntimeVersion, that you can set to false. Setting that to false
will keep the plug-in from upgrading itself. For the time being, I would set that to false, so that you are certain that the computer does not make initiate an update while using your application. I will look into this for you, because I am curious myself.
(I'm almost positive there is a way, I'm just very sleepy.)
biondi
Member
9 Points
22 Posts
How to control Silverlight runtime version
Mar 07, 2009 07:43 AM | LINK
For a Silverlight app compiled and tested base on runtime 2.0, there is a chance that the client upgrade to Silverlight 3.0 (in the future) before my app compiled and tested base on 3.0.
I think the runtime is "generally" backward compatible. But for mission-critical app, is there a way to enforce a Silverlight app to run on a specific version of runtime?
In the Appmanifest.xml, the <version> tag seems not fulfil the requirement.
The minimum version of the Silverlight runtime required to run your Silverlight application. For example, if you set the value of this element to 1.0, the user must have version 1.0 or greater of the Silverlight runtime to view it. If you leave this value blank, the user will be forced to download the latest Silverlight runtime to run your application.
fullsailrick
Contributor
3699 Points
829 Posts
Re: How to control Silverlight runtime version
Mar 07, 2009 07:52 AM | LINK
biondi
Member
9 Points
22 Posts
Re: How to control Silverlight runtime version
Mar 07, 2009 10:01 AM | LINK
Thanks for the reply.
I did study the minRuntimeVersion. That is the minimum Silverlight runtime that your Silverlight app expected to be compatible. But my question is that I cannot assume a newer version of runtime works with my app which is compiled and tested using an older version of runtime before our own testing. However, I cannot control the version of runtime used on customer's machine.
In other words, the requirement is to enforce a "specific" version, NOT a minumum version.
fullsailrick
Contributor
3699 Points
829 Posts
Re: How to control Silverlight runtime version
Mar 07, 2009 10:16 AM | LINK
fullsailrick
Contributor
3699 Points
829 Posts
Re: How to control Silverlight runtime version
Mar 07, 2009 10:31 AM | LINK
That function returns a bool, you can do a simple check during your app's construction. :)