The roadmap for Smart Client

Heres my take on smart client. Your doing smart client if:

  • the application runs on the desktop
  • the application is composable (ie. navigation, controls, workspace and utilities)
  • parts of the application are downloaded on demand
  • parts of the application may be updated as new versions become available
  • the application is not sensitive to changes to network status (ie. it can work offline in some capacity)

Smart Client can definitely improve the user experience over a browser. One example is the utilisation of a local data cache, something that is not possible currently on a browser stack. With a smart client you can leverage SQL compact edition to provide this functionality. You can then utilize SQL Compact's replication as a mechanism to synchronize data with the server. Additionally, you can leverage the new ADO.NET synchronization services (shipping in Orcas, but will support Visual Studio 2005) to provide a finer grained control of synchronization.

The Roadmap for Smart Client is quite exciting there are many options. The roadmap for smart client leads to:


On June 5, David Hill of Microsoft announced the coming of a new client application development framework code-named Acropolis.   It is intended to make it easier for developers to build and manage modular, business focused, client applications for Microsoft Windows on the .NET Framework. Acropolis is aiming to significantly reduce the things that you will need to write code for.

One of the catalysts for this framework is the patterns & practices work in Smart Client Software Factory and the Composite Application Block. As far as patterns & practices client program is concerned theu have no plans to release further version of the  Smart Client Software Factory (SCSF). Not that they are ruling it out entirely either.The message from the Acropolis team is if you are building an application continue to do so using the SCSF. The patterns and practices team will be working tightly with the Acropolis team to provide a migration path to Acropolis when it ships (at least 1 year away from release). It is also not impossible that a subsequent release of SCSF, in the interim,  will aim to move people closer to Acropolis.

One of the things missing in the first version of the SCSF was the ability to create and host WPF. In SCSF v2 (May this year) it includes the ability to use WPF smart parts.This means you can take an existing SCSF / CAB Application and start adding new WPF Workspaces and Smart Parts. It leverages the WPF interoperability control to make the CAB application treat it like any other workspace ot part.

This is important as Acropoplis will provide pre-made application templates (Part Library, WPF Application, WPF Document-Style Application) as the default. If your plan is to migrate to Acropolis then using the WPF Interop capabilities (Windows Shell / WPF Smart parts) or using WPFCAB a community port of CAB to WPF that is in the SCSFContrib may be the way to go.

See more in Glenn's article "Acropolis, the future of Smart Client". If you like the details then its well worth reading Enterprise WPF Applications come of "Age" with Acropolis to get an idea of where Acropolis is going. There is also the WindowsClient.Net site containing videos and deep-dives explaining the how-to with the Acropolis CTP. David Hill also has a video introducing Acropolis.


There are alternatives to Smart Client that are worth considering, includuing Rich Internet Applications (RIAs) 


Silverlight is on the long term roadmap, though it may be a while before it is used for LOB applications. Microsoft Silverlight is a cross-browser, cross-platform plug-in for delivering the next generation of .NET-based media experiences. 1.0 is almost released but with the Silverlight 1.1 release, things start to get interesting with the .NET framework running in the browser and will be supported in more browsers such as Firefox, Safari, etc. Its probably too early to expect Silverlight guidance for smart client type applications, besides Silverlight is really a hybrid of Smart client and Web Client. It's probably too early to make commitments for business applications.


Ajax enriches existing and new web applications by providing the UI styles and framework code for accessing remorte services and data. The Web Client Software Factory details a comprehensive set of guidelines for creating architecturally sound Web applications using the latest Microsoft technologies. The next version of the WCSF will be focused on rich/responsive applications with AJAX for existing and new web applications. There will be some clean guidance on common LOB scenarios leveraging AJAX.

A nice little site on AJAX design patterns can be found here.

The key thing about web application is that there are typically not able to deal with being offline or accessing local resources without applying custom controls (which then limits the platform independance). One other solution might be worth considering, but may result in a greater dependance on available bandwidth:

Terminal services (and RemoteApp)

This could be the cheapest option of having the application available to clients on different operating system, as it won't require a dual development effort. In Windows Server 2008 there is a new feature called TS RemoteApp that will provide the ability to terminal service to a remote application only (ie. no operating system access - window only). Essentially is enables remote users to access Windows-based programs that are installed on a terminal server.

TS RemoteApp can reduce complexity and reduce administrative overhead in many situations, including:

 Branch offices, where there may be limited local IT support and limited network bandwidth.

 Situations where users need to access applications remotely.

 Deployment of line-of-business (LOB) applications, especially custom LOB applications.

 Environments, such as "hot desk" or "hoteling" workspaces, where users do not have assigned computers.

 Deployment of multiple versions of an application, particularly if installing multiple versions locally would cause conflicts

Thanks to Michael Puleio, Tom Hollander and Glenn Block for the p&p specific details