I think biggest advantage of desktop clients over web applications is freedom in UI design, and you don t have to worry about any inconsistencies in the client environment, although those are not an issue if you are using a client that runs on silverlight.

Personally I don t like web applications that requires a lot of user interaction, there are some of them that is a pleasure to use but I think it is very easy to do it the wrong way and end up having a buggy or not so responsive application (probably because of the incompatibilities in browsers, I have IE, Firefox and Chrome installed on my computer and I use one for some websites because they run faster on it, and others for other sites because web pages show up correctly only on them). Though this might not be an issue for a silverlight client.

In case of network speed, depending on the things that goes on the wire even with binary serialization remoting might have quite a bit of overhead. For example along with the data it writes full class names, library names and their versions so it can get pretty big and slow even for small amounts of data (although it should still be smaller then HTTP). It also has the same problems that HTTP has over unreliable connections because it uses a similar protocol. For one project we had to write a custom serializer for some objects because binary serialization alone was generating 200K, but our custom serializer for those objects were generating 50K. Then we ended up writing our own network protocol because the one that comes with the runtime was frequently stalling over unreliable wireless networks, and remoting doesn t give any control on the socket created by it (which makes sense in terms of encapsulation but you can t close it and force it to open a new one).

(I am assuming that you are asking about remoting vs web app. not remote desktop vs. web apps, because of your note about post back, you can t avoid it with a remote desktop session)

Rewriting an application just for sheer speed? No, because probably user won t see much difference in response time.

You are somewhat ambiguous with your terminology - do you want a client app that runs on the user s machine, or do you want an app that runs on the server and the user connects via remote desktop (RDP)?

If you are talking about a client app that communicates to the server via WCF etc., then yes it will be faster than a standard web app, although it will still be slower than a native desktop app. It will be faster than the web app not just because of the lack of postbacks, but also because you will be sending pure data through the wire, not a massive amount of HTML/Javascript combined with your data. With a client app, you have several options so consider them carefully - do you want Silverlight, WPF, or a native WinForms app? Each have their positives and negatives.

If you were talking about having a client app running on the server which the user then access via RDP, then you have other considerations to think of. For any more than two concurrent users you will need to consider buying CALs so the users can connect to the server. At this point you should also be considering whether you should be running a terminal server or Citrix type setup instead of using remote desktop.

Edit

When using WCF over a WAN (internet) you will certainly have to consider how you will secure it. WCF makes it trivial to secure the channel, but you need to consider how you will do authentication - there are a couple of different ways, but you can easily google that stuff yourself. The method you choose will be important due to the limited resources or skill-sets of the users.

As for what you write it in, you can t argue with Winforms if that is where your experience is. Personally, i would never again use ASP.NET/Ajax/etc for a web type application, it would be WPF or Silverlight all the way (i would only use ASP.NET for simple web sites). You can use the express (free) versions of Visual Studio to write it in, you don t need Expression (it s just a nice to have, and is more aimed at the design side than the actual coding side). Deploying the app need not be difficult - Silverlight or WPF xbap are delivered via the web, the user has to do nothing (except for the simple install of the Silverlight plugin or installing the right .Net framework for WPF - check this link). Winforms or stand-alone WPF require slightly more work, but you can avoid most issues by writing a good installer.

Whichever you choose, make sure you don t under estimate the time for development (because you will have a bit of a learning curve), and also make sure you budget enough time for testing it - especially the security side of it :)

I have been in a similar situation, although started with a Winforms LOB application.

Heres what we found with WinForms...

• It s going to be harder to deploy in your release cycle, to all client machines.
• WinForms can t be run on other operating systems easily. (with the exception on mono)
• WCF endpoints can get complicated, and you need to manage an endpoint for release/version of your application.
• Authentication, Authorization and Security can be tricky to get right!

Heres why you should stick to a html web application.

• it s going to be easier to deploy, as you just need to copy one set of DLL s into the bin folder. Can be scripted from a continuous integration or staging server.
• Security is going to be easy, by using a SSL certificate.
• Silverlight/Flash should fill in the gaps that HTML leaves out.

Microsoft has also combined the connected systems in .net 3.5, they now call it WCF (ASMX/Remoting/etc...). It s got quite a learning curve 4-5 weeks.