views:

187

answers:

2

I have a OOB app that did not require elevated trust and was not signed. Many people have downloaded it and use it OOB.

I then needed to use elevated trust features, so I bought a legitimate certificate from Comodo and I now sign it. Everything works great on localhost - it is trusted and recognises the certificate.

However, once I uploaded the new version my existing OOB install (which was the old unsigned, non-elevated trust app) did not do the usual "new version check and update".

This is critical as many people have installed it - is there some limitation on changing to signed, elevated trust with regards to downloads? The .xap name is the same and in the same location. A fiddler lookup sees the new change so it' snot a caching issue. I cleared all my caches with CCleaner to be sure.

I uninstalled the old OOB app on another computer and the signed cert is working fine on install (ie. I get the nice "trusted publisher" install message) so it's not a signing issue. You can see it live here (I will leave the new version up as there is no harm - the old users just wont know about it!)

I believe it is something to do with the Elevated Trust change?

Update: I did some more testing: I removed the Elevated Trust and uploaded it again. The OLD one that did not update then DID update, and the new one (elevated trust + signed) on the other computer did NOT update. So it seems as they the update process cannot handle a change in the Trust elevation, regardless of whether it is signed or not. This is a BIG problem with all the users who will be stuck on an old version and never know it.

The other problem is that the NEW signed app thinks that the app is install on my computer (the old unsigned one that does not update) and hence will not show the Install option. And very few users will know how to uninstall it and reinstall it IF they even went to the website one day to check. This is a really serious bug if it is the case.

A: 

After receiving no reply/leads I am unfortunately coming to the conclusion that this is a bug in SL4.

I assume that because the app now requires a UI confirmation to confirm the elevated trust there is no way for the existing non-trusted app to handle this UI on update, so it just doesn't download it.

For some reason, removing elevated trust has the same issue (trusted OOB apps wont update the non-elevated trust update either, which is even wierder).

So it seems to me the bottom line is that if you change Elevated Trust, you have just isolated all the people who have already installed your app.

So then there seems to be 2 options:

  1. Just update the app and rely on blogs etc. to tell them that they have to uninstall it and reinstall it. This sucks because they wont KNOW that there is a knew version and could use the old version for another 10 years without knowing. Plus, if they go to the online version, it thinks it is already is installed so wont offer the Install menu again until you uninstall the old one - very messy! I think this is the route that Tim Heuer took here with the signed Facebook app - http://timheuer.com/blog/archive/2010/04/15/silverlight-client-for-facebook-updated-for-silverlight-4-release.aspx

  2. Rename the .XAP file and start a new project for it. Make the old .xap file have a message saying "There's a new version" with uinstall and reinstall instructions/links. Then if they view the new one without having uninstalled the old one it will still install as it is a different XAP name, AND you can at least communicate with them telling them the old one is dead.

Any other suggestions?!

Rodney
+1  A: 

Unfortunately, your users will need to uninstall and reinstall the application. It's not a bug as such (I don't believe), but more by design. If you take a look at this article on MSDN: http://msdn.microsoft.com/en-us/library/dd550721(VS.95).aspx, you'll see that it states:

Silverlight 4 provides support for running out-of-browser applications with elevated trust. Trusted applications cannot use the update mechanism described in this section unless the application and the update have both been signed with the same valid, code-signing certificate. To update a trusted application that does not have a valid signature, users must uninstall the old version and install the new version manually.

It more or less seems to indicate in the last sentence (in a round about way) that users with the unsigned application will need to uninstall the application, and then install the one with elevated trust to update it. I've read something that stated this in a more exact way, but can't remember where it was sorry :(.

Hope this helps...

Chris

Chris Anderson
hey Chris! Thanks, I found that article eventually - thanks for confirming. It just seems like a really strange user-experience; if you ever sign/elevate trust your app in the future you WILL isolate all your existing OOB installs out there. A better way of handling it would be to show the user the "This program requires elevated trust - do you want to update" - on the next OOB version update check instead of just stopping dead in the water... I handled it as I mentioned above in Point 2 - at least I will not loose all my exiting users if they make the effort to reinstall it.
Rodney
I agree completely - the way it currently is means that you have to identify the need for elevated trust *before* you first deploy your application. Have you added it as an request to the Silverlight user voice site?
Chris Anderson
Have done - http://dotnet.uservoice.com/forums/4325-silverlight-feature-suggestions/suggestions/1090321-handle-changed-elevated-trust-installations-better
Rodney