Silverlight as front-end for business application

We are developing a new .NET based commercial application which will have a back-end running as a service on a Windows server (optionally Azure). For this, we are considering using Silverlight as the only front-end / GUI for accessing the application - primarily be开发者_开发百科cause this will allow for easy access from various client OS platforms. Users of the application (companies licensing it) will be running the back-end service themselves - we will not be selling this as a service - it will be an "old fashioned" shrink wrapped application.

Would you consider Silverlight mature enough for this?

Do you know of any existing commercial applications that work like this?

Any specific advice / things to look out for implementing something like this?

---

Yes, Silverlight is mature enough.

I started developing with it in July 2008, and shipped the first version of a deployable client/server agricultural telemetry monitoring system eight months later. Despite a few hiccups and underdeveloped areas (moreso with 2.0 than 3.0), I found it infinitely better than Windows Forms for developing a fast, interactive client UI--and don't even get me started on a comparison with the usual www technologies...

I highly recommend it, especially in combination with WCF Data Services or RIA Services for business apps.

---

I've used Silverlight as the front-end to a commercial app for the medical industry. No serious pitfalls, just make sure you spawn threads to handle time-intensive work so the UI doesn't freeze up on you, and make sure to have the clientaccesspolicy.xml file in place if you're accessing web services.

Two 'business' problems addressed in Silverlight 3 are the lack of error handling (semi-resolved) and support for message-based security. Addressing those problems does a lot for Silverlight in its attempt to sell itself as a business-ready technology. My opinion is that it's good enough.

With SL2, there were two limitations that prevented error handling. First, server exceptions come through as response code 500, which browser plugins are unable to handle. Second, there's no exception support in SL2. SL3 addresses the second concern by adding ExceptionDetail and FaultException classes. The first problem still exists. Response code 500 prevents silverlight from accessing the contents of the response, but as a workaround, you can send back a response code of 200 instead of 500.

SL2 supported only browser-based security. An application developed with that security model could be vulnerable to cross domain forgery attempt by malicious apps with access to cached browser credentials. Message-based security addresses that problem by including the credentials with every message.