Application Release/Upgrade Strategyfor Silverlight Business Application?

Question

I am interesting in hearing if others have addressed release management for Silverlight applications.

I have a business application that is to be released shortly andam concerned about how to "release" updates to this application. Typically this application's users will leave the application open all day (and potentially all night) without reloading it.

What if there is is need to release an change that includes an web service interface change? How can this be deployed w/o causing errors on the client side?

We have grown so used to deploying ASP.Net apps by just dropping the latest code on the server. My only idea currently involves a client version number and a periodic timer on to check for updates.

I would love to know what others have done before implementing this.

Thanks, Mike

Answer 1

I just answered a question on how to make sure that .xap files are not cached by the browser, which might be of some help:
http://stackoverflow.com/questions/2157259/prevent-silverlight-xap-from-being-cached-by-proxy-server/2158030#2158030

But that's no use if the users never reload your application. In my own application this is not a problem since users will be automatically thrown out whenever we deploy an update to the web service. But I like your idea with the timer, I would go with that.

Answer 2

Stating the obvious but don't do anything to annoy your users. E.g. could they spend twenty minutes entering data, nip off to the coffee machine and return to click Submit to find the timer has expired, noticed an update and their work is lost due to a forced restart?

If so, and I admit this hasn't had a lot of thought, if e.g. you have to make changes to the web service that break the current release, could you have the new web service version side-by-side such that users don't get thrown out until the timer has expired and the unit of work is complete? Or is this also stating the obvious?

Answer 3

For server code, i.e. endpoints just do as per normal. for the xap's I think you have a few options depending upon how you handle communications. You could have request contain a version number and if the server has been updated then force some code to reload the client, bit lame, messy but do-able. Perhaps a cleaner solution would be to control the clients session, which presumably is part and parcel with requests to the backedn. When you deploy a new version you could invalidate the client session, perhaps forcing a page refresh with custom logic. If your protocol is push base you could send a command to the client to do what ever you want, for many systems that are on all day its likely that this infrastructure would exist (if u've build it nicely :)). For instance our service layer is abstracted away from the repositories models and view models, in our case we'd could send a logout or perhaps a specific command to kick in some custom logic on the client informing the application is being updated and to refresh your browser when done. Our shell is light weight so our modules (basically other xap's) can be updated in time for the refresh.

Answer 4

I would recommend you to use a solution like mentioned in App Arch Guide:

The Guide Chapter I mean see Deployment considerations.

• Divide the application into logical modules that can be cached separately, and that can be replaced easily without requiring the user to download the entire application again.
• Version your components.

Answer 5

Have you considered keeping a WCF polling duplex channel going that alerts the app when it needs to reload? In addition, you can have your WCF calls direct to a virtual directory that contains 'interfaced' calls. For example:

Silverlight app hosted at "x.x.x.x\Default.aspx" Silverlight talks to WCF at "x.x.x.x\Version2\DataPortal.svc" DataPortal.svc talks to a GAC (or otherwise base) assembly that can identify what version can handle what calls.

This way, if you upgrade to "x.x.x.x\Version3\DataPortal.svc", you can still make calls against Version2, assuming those calls have code to convert them to a Version3 concept.

This helps in cases where your line of business app has dynamic xap downloading ('main', 'customer', 'inventory', etc.) and you want to release them independently.