Silverlight, Wpf Web App (xbap) or Click Once? Pros and Cons

Question

We are starting a new project and I\'m trying to decide which of the Wpf-esque develop/deploy strategies we should go with. In our case we are looking at quite a complex bus

Answer 1

I would consider WPF ClickOnce with sync framework support (www.msdn.com/sync). This would allow you to support limited functionality when the user is not connected to the corporate network (which will eliminate any browser-based deployment scenarios, such as Silverlight and XBAP).

Answer 2

1. Silverlight can access the DOM from the hosting page and
2. the hosting page can access the Silverlight part.
That's a big + for Silverlight

But all other limitations cry for WPF/Windows-Forms with Clickonce
file access, right mouse click, ease of db access

Answer 3

First, I would evaluate whether a web client (ideally MVC+jQuery) can't do the job...

Assuming a full client is warranted:

If it is a business app that demands a client, I would tend to go with the full framework and ClickOnce; the main difference here (re deployment) is that the client must have the framework installed - but past that, ClickOnce deployment is very pain free. Actually, building a ClickOnce manifest is much easier than Silverlight etc, since the IDE will do almost all of it for you; you just have to host the files somewhere (could be a web URL; could be a network UNC).

This gives you much more control (and power) at the client, as well as a far greater range of existing resources to use (for example, if you need, you can use some legacy winform code on the WPF surface). The "requires full framework" is also one of the largest benefits: "has full framework".

You should also perhaps consider the 3.5 "client profile" setup; not sure how wide-spread this is in reality... but worth knowing about.

Answer 4

The pros

1. The Silverlight plug-in means developers can target a single, consistent runtime for browser-based applications, rather than dealing with the complexity of multiple browsers in different versions. You also get video and multimedia effects that are hard or impossible with pure HTML and JavaScript, though Adobe Systems' Flash has the same advantages.
2. Execute .NET code without deploying the .NET runtime. The Silverlight plug-in does include a cut-down .NET runtime, but instead of dealing with a large download and the complexities of the Windows installer, the user has a small download of about 4MB, all handled within the browser. In my experience so far, installation is smooth and easy.
3. Performance is promising. Silverlight comes out well in this prime number calculator, thanks no doubt to JIT compilation to native code, though it may not compare so well for rendering graphics.
4. Support for Moonlight means there will be an official open source implementation of Silverlight, mitigating the proprietary aspect.
5. Silverlight interprets XAML directly, whereas Adobe’s XML GUI language, MXML, gets converted to SWF at compiling time. In fact, XAML pages are included as resources in the compiled .XAP binary used for deploying Silverlight applications. A .XAP file is just a ZIP with a different extension. This also means that search engines can potentially index text within a Silverlight application, just as they can with Flash.
6. Third-party component vendors are already well on with Silverlight add-ons. For example, Infragistics, ComponentOne and DevExpress.
7. Take your .NET code cross-platform. With Macs popping up everywhere, the ability to migrate Visual Basic or C# code to a cross-platform, browser-based Silverlight client will be increasingly useful. Clearly this only applies to existing .NET developers - I guess this is the main market for Silverlight, but it is a large one. The same applies to the next point:
8. Uses Visual Studio. Microsoft’s IDE is a mature and well-liked development environment, and since it is also the tool for ASP.NET you can use it for server-side code, as well as for the Silverlight client. For those who don’t get on with Visual Studio, the Silverlight SDK also supports command-line compilation.
9. Choose your language. Support for multiple languages has been part of .NET since its beginning, and having the .NET runtime in Silverlight 2.0 means you can code your client-side logic in C#, Visual Basic, or thanks to the Dynamic Language Runtime (DLR) Iron Ruby or Iron Python.
10. Isolated storage gives Silverlight applications local file access, but only in a protected location specific to the application, providing a relatively secure way to get this benefit.

The cons

1. If Apple won’t even allow Flash on the iPhone, what chance is there for Silverlight?
2. Silverlight is late to the game. Flash is mature, well trusted and ubiquitous. Silverlight 2 only comes out of beta in the Autumn (we hope). It is the version we care about - the one that includes the .NET runtime - and will still lack support on mobile devices, even Windows Mobile, though this is promised at some unspecified later date.
3. The design tools are Expression Blend and Expression Design - but who uses them? The design world uses Adobe PhotoShop.
4. While having solution compatibility between Expression Blend and Visual Studio sounds good, it’s actually a hassle having to use two separate tools, especially when there are niggling incompatibilities, as in the current beta.
5. No support for the popular H.264 video codec. Instead hi-def video for Silverlight must be in VC-1, which is less common.
6. It’s another effort to promote proprietary technology rather than open standards.
7. Yes Linux will be supported via Moonlight, but when? It seems likely that the Linux implementation will always lag behind the Windows and Mac releases.
8. Silverlight supports SOAP web services, or REST provided you don’t use PUT or DELETE, but doesn’t have an optimized binary protocol like Adobe’s ActionScript Message Format (AMF), which likely means slower performance in some scenarios.
9. Silverlight is a browser-only solution, whereas Flash can be deployed for the desktop using Adobe Integrated Runtime (AIR). Having said that, yes I have seen this.
10. You have to develop on Windows. This is particularly a problem for the Expression design tools, since designers have a disproportionately high number of Macs.

Answer 5

You can add to the pros and cons of the usual stuff of the online vs offline debate. Some items:

Pros

wpf(offline):

• better access to low level parts of the computer.
• cpu usage is local, so you rarely have cpu load issues.
• not dependent of the net.
• no downtime for maintenance.

silverlight(online):

• Better control of users. If your users login, you dont have to worry with activation keys or similar stuff.
• It works on Windows and Mac.
• You can update all your users apps easily.

I simplified it a bit, there are gray areas in the list. I only tinkered with XBAP, so that one I'll leave out. The Cons are not hard to figure out after looking to the pros.

HTH

Answer 6

If you don't need all WPF I would try do it in Silvelight first Then you can switch to WPF more easily if you need it later.

Here I think it applies the “less is more” principle: it’s true that with WPF you have much more options and can access to the user computer, but that can finally be more a problem than a help as the times go. Think for example in how many changes you can need to change from Windows XP to Vista in an application that uses a lot of the “user computer” resources!