Hi Colin, I tried to build the XAMLFinanceWPF solution, but I keep getting an error telling me "Cannot resolve dependency to assembly 'System.Windows, Version=xxx, Culture=neutral, PublicKeyToken=xxx' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event."
I googled this, and the consensus is that this is due to mixing Silverlight and WPF... how did you get around this error?
Hi Dragan, glad you liked it. The reason I did not use PCL is because I had not heard about it when I started working on this code! Unfortunately the code-share potential is not great, ViewModels with ObservableColletion properties are not portable beyond Silverlight / WP7, although it does look like there is a workaround here:
Before supporting this kind of architecture though, you've got to ask yourself, do I really need WPF? We asked that question early on after starting a complex LOB application using Silverlight / WPF / WP7, and we quickly realised that it wasn't worth it to support WPF.
WPF increases client footprint and cost of ownership dramatically, whereas Silverlight running directly from a browser is virtually free in this regard. Installing a Silverlight app as OOB can simulate the desktop experience quite well, and it has the added advantage of adding more capabilities through elevated privileges. There is also the option to scale the Silverlight model to cloud-based SaaS as well.
Developing both WPF and Silverlight in the same architecture becomes increasingly complex as the size and complexity of the app increases and the QA effort is practically doubled as well. Given that these two technologies are largely converging anyway, and the general ecosystem for Silverlight is evolving quickly, I would suggest that Silverlight may be 'good enough' by itself for a large number of applications.
If you can honestly say, supporting WPF adds real value for our customers, then by all means do it, but be aware of the significant development and testing cost that will come with it.
You make some excellent points there. Silverlight has been evolving fast, with many of the more advanced WPF features being added to the latest versions of Silverlight.
If you don't need tight integration with the Windows desktop (i.e. access to file-system, registry), or 'legacy' interfaces (ADO.NET DataTables, direct access to SQLServer), then Silverlight is a typically a much better option. It gives you cross-platform (Mac & Windows) and a simpler distribution model (web and OOB).
Now ... what about Win8 WinRT? Where does that fit into all of this!
(By the way, I am porting XAMLFinance to WinRT at the moment, sharing the code-base across all four XAML frameworks).
Yes, that old chestnut - for me the answer is simple right now: I have no frikkin' idea.
I hope that they are forced to change their mind on IE10 and allow Silverlight as a plugin, otherwise Silverlight really is finished - I also hope that they get out of this 'app store' modality and start thinking about how WinRT could be leveraged efficiently by all types of apps, not just those targetted at consumers.
And I REALLY hope that this talk of all existing Win32 / Win64 / .NET applications suddenly becoming 'legacy' is just FUD.
Fun times are ahead (and we really should be used to all this churn by now, shouldn't we?)
Super stuff. I found this article to be a very good read.
Another problem I noticed was that if one has used a "recommended" pattern like Microsoft Prism in WPF or Silverlight, one is going to run into some roadblocks migrating to WP7.
Prism has a subset available for WP7, but does not support regions or modularity! That can be a huge roadblock in terms of migration (or even new design).