10

I'm in the initial planning phase of a re-write project and I'm deciding between silverlight/silverlight oob/wpf. TL;DR at the end.

It's a LOB app that handles leads/customers/appointment calendars. Not too complicated. I'm independently researching these options elsewhere, but I thought I'd ask around. Some rough initial requirements/foreseeable problems are:

I have to be able to call an exe on the system with commandline args (sip phone).

Makes SL a problem

The userbase is distributed and I want to limit the traffic that goes over the wire as much as possible and avoid some nasty concurrency issues

I can see this being a problem using WPF

Software deployment/updating has to be dead simple. Some users are highly non-technical (see: 70 years old, on a computer for the first time)

This isn't a huge problem now with the ClickOnce app we are replacing, and I have control over the machines that it gets used on. However, it's simpler for users if they don't even have to click the clickonce "Install" button. I don't know how this is handled with Silverlight OOB.

The company is planning a hard expansion in 12 months so hardware deployment should be fast/easy. The idea is to get an internet connection at a new location, plug in some computers and be able to work without the need for dedicated IT people or server setup.

Makes SL appealing

Integration with other services (financial software, asterix server) isn't an immediate goal, but it is an eventual goal to be part of the system. This is made much simpler/more efficient if a single service is setup to integrate with those secondary services and doesn't have to transfer all of that data over the wire

Makes SL appealing

Making multiple 'versions' is out the window. I don't know what it's like maintaining a silverlight + silverlight oob version (if there's even any problems)

Might make WPF a better option.

TL;DR: From my vantage point, a silverlight app makes the best sense for 90% of the users - the other 10% can't use it because they need to run an exe. Silverlight OOB might be a happy middleground but I don't know at the moment what the execution model for it is like (is there still a concept of server-side code? If so, that would possibly be ideal) and I don't know how deployment/updating works for it.

Steven Evers
  • 28,200
  • 10
  • 75
  • 159
  • Why do you want to replace the ClickOnce application in the first place? ClickOnce has an option to check for and download an available update at startup of the Application automatically. I have done that see http://replayer.codeplex.com – Marcel Feb 12 '13 at 12:15

3 Answers3

6

Well - interesting problem. You forgot to mention that you can have a Silverlight full trust application as of SL4, so if you're thinking of WPF you might want to consider that instead. It would need installing (ClickOnce), but you seem to be moving away from that.

I've not done anything with OOB yet, but I'm pretty sure that the same binary can be used both in broswer and out of browser as it's a project setting rather than a separate build target.

"Enable running application out of the browser"

on the Silverlight project's Silverlight tab.

So there'd be no separate maintenance issue there.

You can build a fair amount of code into the web application that hosts the Silverlight app and communicate using WCF RIA Services - again you'd have to go with .NET 4 and SL 4 to get version 1.0 of this. .NET 3.5 and SL 4 only supports the WCF RIA services beta. This would reduce a) the size of the download and b) the amount of code that would need to execute on the client but would increase the network traffic.

On that score you can split your Silverlight code into several assemblies and using something like Prism set them to load on demand. This means that the user only downloads those parts of the application they are actually using. You can further reduce the amount downloaded by checking the

"Reduce XAP size by using application library caching"

option.

If you have an "extmap" file to go with any external dlls (third party or .NET) then this means that they get bundled into a zip file and downloaded separately to be shared across all xap files in your project. This keeps the individual xap files to their minimum size and ensures that you only have one copy of these other dlls on the client machine.

ChrisF
  • 38,878
  • 11
  • 125
  • 168
2

Your analysis is very good.

The only other thing that I would mention is that not ALL of the framework is available to you in a Silverlight application. That restriction MAY tilt your choice towards WPF, but you'll need to see how that restriction applies or not to your application needs.

Walter
  • 16,158
  • 8
  • 58
  • 95
  • The app is mostly a crud app, with the exception of the need to call a SIP phone via it's exe + args so I don't think I'll miss any of the missing framework parts. – Steven Evers Oct 27 '10 at 22:27
2

Just a couple of quick things:

Deployment and "server-side code": A Silverlight app is a client-side app, plain and simple. Don't let the mere fact that it is delivered through the browser confuse you - when you run an in-browser SL app, you are downloading the assemblies for that app in a zipped package, extracting them, and running them using the plugin. Silverlight by itself has no notion of "server-side code" - if you want code to run on a remote server, write a WCF service.

Updating the app: This is a common scenario for OOB apps and SL has built-in support. Google around for CheckAndDownloadUpdateAsync.

Edit: Forgot to mention - installing the application is done from within the application. By default, an installable SL app will have a context menu action to install it. However, installing can also be done programmatically in response to the user clicking a button. The install state can also be detected programmatically, so what I've seen some SL apps that are only intended to run OOB do is first detect if they are installed. If so, run the app. If not, just show a splash screen with a button that installs the app.

nlawalker
  • 3,002
  • 20
  • 21