Hi!
I have been using WPF for a while, and I keep on realizing again and again that Microsoft invests its efforst in Silverlight, not in WPF (RIA Services, default theme, controls and more).
I thought it might be a good idea to migrate to Silverlight (i.e. creating standalone desktop apps with Silverlight 4.0), the question is whether this is possible or not.
BTW, I think LightSwitch applications are generated with Silverlight as standalone desktop apps.
If you mean Out of Browser apps, certainly. The Seesmic Desktop 2 app is an excellent example of one of these apps, with it's own updating mechanism. Seems a no brainer to use the XAP/MEF plug-in Model and Silverlight in this manner. Seesmic Desktop 2
We're developing an OOB app along the same lines, one internet download and you're done. You're not going to get exactly the same APIs as you get in WPF, though.
Silverlight 3 supports Out-of-Browser functionality.
Quote from Wikipedia silverlight page :
Silverlight 3 supports Out-of-Browser experiences, i.e., Silverlight applications can be installed to the system for offline access (provided the application manifest is designed to allow local installation) where they run outside the browser.
Also here is a quick howto
From MSDN:
Silverlight 3 applications are no longer restricted to running in a browser. They can be run in a browser or it they can be detached from the browser and run from the desktop. These out-of-browser applications allow you to bring the richness of Silverlight 3 applications directly to the desktop without the restriction of running within a browser.
Out of browser applications have the same security restrictions as in browser applications.
With Silverlight 4 you can create full trust applications which have full access to the computer.
It is possible to create standalone desktop apps(Out of browser apps) with silverlight version 3.0 or higher and it works great. Now it is also possible to install the out of browser app even without opening a browser as shown at this blog post .Silverlight is awesome and silverlight apps even run on MACs and Linux(limited support)
However, it is not true that Microsoft is only investing in silverlight. Microsoft is investing in WPF too. Though it is possible to create out of browser applications with silverlight, they have lot of limitations when compared to a full blown WPF applications.Dont forget that silverlight is just a subset of WPF, for example, silverlight doesnt have ADO.NET, Hardware device access etc. So if your application is merely a business application and you dont have to access hardware devices or database directly then silverlight might be an option, however if your application accessing client machines hardware resources directly then you are better off with WPF.
My suggestion is, If you know before hand that it is going to be a desktop application then go with WPF(or may be even XBAP). In my experience, useful applications grow with time, new features are always requested time to time. If in future,a feature is requested that cannot be accomplished with silverlight and can only be accomplished with WPF, then you will be in a big trouble because you need to rewrite your app in WPF and it will be hard for you to convince your CFO to allocate more fund just to implement one feature. Silverlight is not designed to develop desktop applications, its main goal is multi-platform support.
As others have pointed out, Silverlight apps can be installed to run 'out-of-browser', but even with elevated trust they still have significant restrictions on what they can do and certainly don't have "full access to the computer".
Creating an app from scratch, you may want to consider parallel Silverlight & WPF builds. The code can more-or-less be shared by adding the .cs files from one project (e.g. WPF) to the other (Silverlight) using "Add As Link". The XAML files cannot be linked this way and need to be duplicated, but that may not involve much more than copying & pasting, depending on your structure. There're good examples of this on the web.
Developing both types in parallel would likely involve a lot less effort than having to abruptly switch types at some point and discovering incompatibilities/limitations too late.