Portable Class Libraries under Metro WinRT

by Administrator 7. April 2012 18:39

Source code: http://SolrContrib.CodePlex.com change set: 97145

The beauty of Composite Applications is that they are resilient to change; in reading Scott Hanselman's blog, and having commented on my experiences with Portable Class Library (PCL) issues with Metro, I was informed by Scott, David Kean and others that the issues were resolved with the beta release.  Considering the sources, I refactored my http://SolrContrib.CodePlex.com application and, with David Kean's help, I was able to get my PCL port of Unity (and new port of Prism) plugged into the framework in a short period of time.  

In the figure below, the Portable Class Libraries are highlighted in green. I pulled out the MetroIOC container (the only IOC container available for the Metro developer preview) along with the Prism bits and replaced them with the following three portable class libraries: Gwn.Library.Prism.Portable, Gwn.Library.Unity.Portable and Gwn.Library.Portable.   I was very impressed with the power of the PCL framework - the required reflection components were available to create ports of both Prism and Unity (scaled down significantly which is to be expected).  The power of the PCL framework is SIGNIFICANT because it permitted me to refactor most of the framework API classes, which were dependent on Prism and IOC, into the Gwn.Library.Portable classes - the only classes that I couldn't migrate were those that had dependencies on Windows components such as Controls and Visibility; they remain in the Gwn.Library.Desktop and Gwn.Library.Metro projects as applicable.

I love the fact that PCLs will work on all platforms.  I went through some rough cycles with Multi Targeted development; I first started with developing to the least common denominator but it turns out that these are the most fragile, i.e., on new releases Silverlight or Metro projects (the primary source code) won't load but the desktop applications always seem to survive the process.   This time I place the source code in Desktop applications and have the Metro (and upcoming Phone) projects link to them.   I will develop to the most common environment (desktop) and deal with compile issues during compile time.  Since I'll have Metro projects linked to the desktop source, issues won't get past me I just won't have the benefit of intellisense to tell me that I'm coding in a manner that will not compile on a different platform. 

As for Silverlight... I remember going to a FoxPro conference in which Microsoft dominated the conference with the topic of this thing called .NET.  I then got to watch Visual Basic get pushed off the cliff  - deep down I had to smile because as a FoxPro, objected oriented programming, developer I was always feeling like the step-child (to VB), now I see .NET moving in the direction of FoxPro (with Linq queries against data), which I jokingly refer to as FoxPro 11, anywho's I'm digressing...  I see the warning signs and since my target audience will be Windows 8 and its IE browser won't support plug-ins (Silverlight) it is a moot point to travel that path.  Instead I'm going to dig deep into JavaScript projects and ASP.NET MVC4 when it comes time to stand up the web components of my framework - components that will reuse all existing architecture.