Our team is divided on this and I wanted to get some third-party opinions.

We are building an application and cannot decide if we want to use .Net WPF Desktop Application with a WCF server, or ASP.Net web app using jQuery. I thought I'd ask the question here, with some specs, and see what the pros/cons of using either side would be. I have my own favorite and feel I am biased.

Ideally we want to build the initial release of the software as fast as we can, then slow down and take time to build in the additional features/components we want later on. Above all we want the software to be fast. Users go through records all day long and delays in loading records or refreshing screens kills their productivity.

Application Details:

  • I'm estimating around 100 different screens for initial version, with plans for a lot of additional screens being added on later after the initial release.
  • We are looking to use two-way communication for reminder and event systems
  • Currently has to support around 100 users, although we've been told to allow for growth up to 500 users
  • We have multiple locations

Items to consider (maybe not initially in some cases but in future releases):

  • Room for additional components to be added after initial release (there are a lot of of these... perhaps work here than the initial application)
  • Keyboard navigation
  • Performance is a must
  • Production Speed to initial version
  • Low maintenance overhead
  • Future support
  • Softphone/Scanner integration

Our Developers:

  • We have 1 programmer who has been learning WPF the past few months and was the one who suggested we use WPF for this.
  • We have a 2nd programmer who is familiar with ASP.Net and who may help with the project in the future, although he will not be working on it much up until the initial release since his time is spent maintaining our current software.
  • There is me, who has worked with both and am comfortable in either
  • We have an outside company doing the project management, and they are an ASP.Net company.
  • We plan on hiring 1-2 others, however we need to know what direction we are going in first


  • General users are on Windows 2003 server with Terminal Services. They connect using WYSE thin-clients over an RDP connection. Admin staff has their own PCs with XP or higher. Users are allowed to specify their own resolution although they are limited to using IE as the web browser.
  • Other locations connects to our network over a MPLS connection

Based on that, what would you choose and why?

  • I love all the votes, but would really like to hear some more opinions on this :)
    – Rachel
    Nov 19, 2010 at 18:10
  • 3
    what are you doing that requires 100 screens initially? Nov 24, 2010 at 8:36
  • That estimate includes a lot of partial screens. For example, the main screen is broken down into a bunch of "pieces" which can be added/removed/moved/resized according to the user's needs. Each has their own set of data, own editing view, and its own set of actions that can be performed. I am counting these as separate instead of a single screen since each is very different.
    – Rachel
    Nov 24, 2010 at 13:33
  • Use .NET MVC 3, JQuery and HTML5 Mar 2, 2011 at 21:54
  • 1
    Hi @kmote, we ended up going with WPF and were quite happy with the decision. It allowed for a lot more flexibility in building the user interface, and I found it was quite fast to build compared to a web based solution. Sadly, the project got cancelled after a year due to other priorities, however if I were presented the same choice again I'd make the same decision.
    – Rachel
    Feb 26, 2014 at 17:07

8 Answers 8


It certainly sounds to me like a WPF app, with lot's of user interaction and potentially interacting with hardware. You can deliver the app via Click-Once so deployment is mostly a non-issue. Your WPF app can access a WCF service and deliver the data as binary so the performace will be excellent. I would start reading up on WPF and getting familiar with it as soon as possible.

  • +1 Also, with ALL those screens, you'll probably want build as much re-use as possible into your app (both code and GUI) Nov 23, 2010 at 23:18
  • +1 I guess with "Softphone/Scanner integration" required, I guess the only way is WPF. Or maybe its possible to use Silverlight
    – Jiew Meng
    Nov 26, 2010 at 7:38

Lunatic fringe answer: both. Get the service layer right, it is easy to have a thick client that does everything (WPF) and a quick web client to do most common things (ASP.NET). Leaves door open to mobile client, etc., down the road.

  • That's what we're thinking of doing.... WPF client application for most uses with a lightweight web version for reports or limited access.
    – Rachel
    Nov 23, 2010 at 18:57
  • 2
    +1 to this, write the non-presentation guts in whatever .NET language you're comfortable - then use the best tool for each presentation task (ie: web app use ASP.NET interface to this application, desktop use WPF/Winforms/etc).
    – bly
    Nov 24, 2010 at 14:13
  • Initially users may find the ASP.NET 'good enough' especially if it means getting more pieces of the app sooner.
    – JeffO
    Nov 27, 2010 at 17:31

If you only have one programmer who has been learning WPF and you are considering having your team take the jump to WPF then why not use Silverlight instead? You get many of the advantages of WPF but still maintain the ability to leave your project as a web app. Since you are looking at having a large modularized project it would make sense to use PRISM with WPF or Silverlight to make MVVM simpler.

My team recently made the choice to use Silverlight over asp.net. It has been a fantastic choice for us. We initially had only a single developer who knew any silverlight. Then we all took a week training class that was mostly useless, but at least got our feet wet. In the end we had to hire two contractors to help us with the creation of the bulk of our UI framework. The majority of our team still is not confident in their silverlight skills. Myself, the initial team member with knowledge of silverlight, and the two contractors are the ones doing the bulk of the SL development. After that we have two dedicated back-end members. I would say it took us about 2 months after making the decision to move to Silverlight that we really had anything concrete put together. However, now we have a wonderful product that feels very much like a client side application that is running inside of a web browser and does not be installed on any machine locally. Development has been under a year in total and we're near ready to release or first release candidate.

Some things to consider:

  • WPF or silverlight, whichever you choose there will be a fair amount that your developers will need to learn.

  • Silverlight can run out of browser if need be. If you do this it is pretty easy to set it up so that if you ever roll out a new version then the installed out of browser SL program will automatically update itself.

  • Silverlight does not include all the controls that WPF has.

My final note is that if you want to churn out code as fast as possible then its pretty obvious you should go with ASP.NET. My major qualms with ASP is that unless you discipline your team it is easy for an ASP.NET project to become cluttered and messy. If you think you will be able to deal with the initial overhead of getting up to speed with the technologies then Silverlight or WPF will allow you a lot of wonderful possibilities.

  • We are in a very similar situation and I found it interesting to hear your story, thanks. I'll consider Silverlight, although up until now I've only used WPF. If we go with WPF we planned on doing our Reporting section in Silverlight, so I had planned on learning it eventually
    – Rachel
    Nov 18, 2010 at 18:43
  • I'm in the middle of converting (read rewriting) an ASP.NET application in Silverlight - basically because the ASP.NET doesn't scale to what we want it do.
    – ChrisF
    Nov 18, 2010 at 23:27
  • 1
    Just FYI: remember that Silverlight isn't going to be a major product of MS, and in some cases, people are saying it may be discontiued. I agree that it would be good to consider, just add this information to your list of possible cons. Nov 19, 2010 at 18:01
  • 1
    I would strongly consider WPF over silverlight for this sort of app. WPF can be easily deployed as an XBAP (xaml browser application), usually with just a couple changes in code to the config file. WPF has everything Silverlight does and more, plus WPF gets a lot more support. The one downside is that while Silverlight can potentially be deployed on more OS's(even Linux with the Moonlight project), WPF requres .Net on the client, so its strictly Windows. Nov 23, 2010 at 19:00
  • 2
    I don't know if Silverlight will be discontinued but something related is the Mashable article Microsoft Shifts From Silverlight to HTML5. Personally, I will seriously consider Pure Web Apps if its possible over desktop or proprietary based plugins where possible
    – Jiew Meng
    Nov 26, 2010 at 7:50

This part is quite concerning:

General users are on Windows 2003 server with Terminal Services. They connect using WYSE thin-clients over an RDP connection. Admin staff has their own PCs with XP or higher. Users are allowed to specify their own resolution although they are limited to using IE as the web browser.

WPF is not great over Remote Desktop/Thin client connections. Animations will not be smooth and any complex images (even gradients) will slow the UI response down to a crawl. Admin staff with typical retro XP machines will also most likely have performance problems with complex WPF applications (because of tiny amounts of RAM and bad GPUs).

If you go the WPF route for rich graphics, be prepared for last minute performance hacks when you find out that the target machines are ten years old. Stick to static screens and use .NET 4.0 as the WPF performance has improved dramatically since 3.5.

  • Thanks... that is actually one big concern for me, although so far it looks like we can scale back graphics if the user is on an RDP connection and tests have run fine.
    – Rachel
    Nov 26, 2010 at 13:11

Technically, I believe the WPF/WCF combination is the better solution.

However, I am not convinced that your existing WPF programmer really has the experience for this project. WPF is quite a shift in programming thought processes from Winform programming and so you will need to think long and hard about do you really have sufficient skills in the team to deliver this route.

  • 1
    +1 'Learning for a couple of months' could mean anything - be prepared for a steep learning curve. Mar 3, 2011 at 1:44

Interesting. That sounds strikingly familiar to an app that we've just started at my company (sip phone and scanner integration and all).

We chose silverlight with a focus on SOA so that a WPF app could be made afterward if the need arises.

Room for additional components to be added after initial release (there are a lot of of these... perhaps work here than the initial application)

We're using MEF in the service layer, and constructing extension points (plugin interfaces describing certain points where we plan extensibility or integration with other systems)

Keyboard navigation

Not a problem.

Performance is a must

What kind of performance? Perceived performance (snappy-ness) or number crunching performance? The latter could be a problem with a web/silverlight app. For the former, our app goes through lots of records, like yours, but we are able to predict them and pre-fetch records while the users are working on current ones. 'Load' times are zero for that section of our app.

Production Speed to initial version

Depends on the skillset. But realistically, everyone always wants to get to market as fast as possible, so it's a non-argument.

Low maintenance overhead

Like production speed, it's also a non argument and it's going to come down to design and coding practices. If you are speaking in terms of hardware maintenance, you might want to go with a cloud app.

Future support

I'm not sure what that means.

Softphone/Scanner integration

Silverlight 4 allows webcam/mic access now (we're hoping to do inter-application video conferencing as well as sip integration), so if you are using a phone server, you can write one yourself. I don't know of any existing ones, but this might help.

Otherwise, you might have to do some ugly hacking (don't have a reference to the article/s anymore, sorry) or you have no choice but to have a WPF app that can interact with the file system. SL4 can go out-of-browser, but it can only access certain parts of the file-system. None of them are likely going to be the parts that you need to interact with a sip phone.

Do you mean, document scanner? I'm not sure about that. We're using hand/barcode scanners, and they operate just like any other input device and are a non-issue.


do you need a higly responsive application for people to use all day long? use WPF ; you'll find it easier to reuse GUI components in WPF over ASP/MVC also (IMHO)

yes, jquery et al are great, silverlight is cool, but desktop apps are still more efficient

for the back-end, WCF is fine


I will have to recommend you to use WCF for your service layer because of scalability and security. For the presentation layer you can use either Silverlight or ASP.NET, Silverlight is like Flash, but it's hard to understand and have a high learning curve at first, mostly when working with data. ASP.NET is easier to use but you will need a lot of tweaking and javascript to use it efficiently.

  • 1
    The plan is to have a WCF service layer regardless of what we choose to do for the UI layer. We're trying to decide if we want WPF/Desktop or ASP/Web for the client application. Even if we do go with a desktop app there is a high chance we will have a web portal to access a subset of items such as reports.
    – Rachel
    Nov 23, 2010 at 18:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.