Reputation: 241485
I'm starting a new project that is primarily a silverlight web application. However, it also needs to run as a stand-alone desktop application.
I'm planning on basing the project on Prism 4.0. It provides guidance around sharing code between silverlight and WPF for a "multi-targeted" application. If I understand correctly, I can use MVVM to create separate silverlight and WPF views for the same view-models and underlying services.
I'm wondering though if it is really worth the extra work to create the extra views, when silverlight can now be run as an out-of-browser application. Couldn't I bundle the desktop version of my app with IIS Express and host the silverlight app locally? It seems like a fairly easy thing to do. I'm sure there are some visually compelling things I can do differently in WPF, but in my case - the web version is where 90% of the usage is going to be, so the focus is clearly on silverlight. If we have to maintain two separate sets of views, I can see the WPF version trailing behind the silverlight version on a regular basis.
On the data side of things, I've already figured out that I can configure Entity Framework to work with SQL CE 4.0 for the desktop version. I would do this even if we used WPF, so it's really just down to the presentation layer.
So to recap, the question is simply this: Is IIS Express + Silverlight OOB a viable alternative to multi-targeting both Silverlight and WPF?
Upvotes: 1
Views: 649
Reputation: 49385
A silverlight out of browser app sounds perfect for your needs. Rather than trying to bundle IIS express and SQL CE, you might want to take a look at something like SterlingDB for local data storage. If you are calling web services, out-of-browser applications running with the "full trust" flag enabled don't have cross-domain restrictions. This way, your app would be pure silverlight, and your deployment & update scenarios would be very straightforward (single-click install via a website).
Upvotes: 1
Reputation: 13940
More than likely, the Silverlight-only version setup would be better, as long as you can live with the sandbox restrictions. Less distinct code to test is always a Good Thing. You haven't specified what the app is doing, but as long as it doesn't need access to (most) local devices, unrestricted filesystem access, or any of the other SL4 sandbox restrictions (which you could also get around with COM interop, but ouch), you should be fine just doing one version of the app with in- and out-of-browser deployment setups.
Upvotes: 2