There’s been a lot of exciting change in cross-platform development for C# developers over the past few months. Microsoft introduced the Universal Apps concept for WinRT (Windows 8 and Windows Phone 8.1), and Xamarin introduced Xamarin.Forms (Windows Phone 8, Android, and iOS).

Beneath the Universal App support in Visual Studio 2013 is a broader concept called a Shared Project. With the Shared Project Reference Manager add-in for VS13 you can reference these shared projects from any project, not just Universal App projects.

As a result, you can build a solution like this one:

This solution includes a Xamarin.Forms MobileApp, a Microsoft Universal App (based on the Hub control), a Windows Forms app, and a WPF app. All of these apps use non-UI code from the NonUICode.Shared project.

In fact, the Android, iOS, WinPhone, Windows, and WindowsPhone UI projects have basically no code at all. In the MobileApp all the UI code is in the MobileApp1.Shared project. In the WinRTApp all the UI code is in the HubApp1.Shared project.

The Windows Forms and WPF apps each have their own UI code. Windows Forms is its own thing, and although WPF uses XAML, it is an older dialect that doesn’t share enough in common with WinRT or Xamarin.Forms for sharing.

None of the UI projects contain any business logic or logic to call services. All that code is in the NonUICode.Shared project so it can be maintained just one time. The service calls use HttpClient, which is reasonably common across all the UI platforms, and for the few differences I’m using #if statements to accommodate the per-platform code. For example, here’s a bit of code from a shared viewmodel class:

The overall result is that with reasonable effort you can create an app that spans every type of smart client technology available today; from Windows Forms up to iOS. These apps can share all your business and service client code, and can often share a lot of UI code.

(fwiw, if you build your business logic with CSLA .NET it is a lot easier to create and maintain the shared business and service client code than if you try to build that code by hand)

A couple of us at Magenic have been spending some time looking into the new Xamarin.Forms technology.

It has some nice potential, but is clearly at the prototype stage more than the ready-for-use stage.

The good potential centers around the start of a XAML dialect they’ve created that describes common UI elements and concepts across iOS, Android, and Windows Phone 8 (Silverlight). Using this dialect you can’t get at all the features of each platform, but you can get at enough features to create standard data entry and data viewing forms like you’d need for a typical business application. And there’s always an easy escape hatch that allows you to build per-platform forms for when a common form just isn’t enough.

The bad points are areas I hope they’ll address soon so the technology becomes more useful for real work.

The first roadblock is the almost complete lack of documentation or samples showing how to use their XAML dialect. They have samples showing how to build forms in C#, but not in XAML. It reminds me of the first few months when Microsoft introduced XAML for WPF.

Perhaps it is because of the lack of XAML samples/docs, but it is a real struggle to figure out how to do things like async loading of data, full implementations of data binding against standard data binding types, etc.

I think this whole thing has potential. WPF was really rough when it was introduced, and eventually Microsoft improved the docs and samples and designer tools. And they eventually smoothed over the most egregious data binding issues, allowing the vast majority of existing .NET types to bind into WPF.

You can download the msi installer from the release page, or better yet add references to the framework via NuGet.

Version 4.5.600 includes support for iOS (via Xamarin) and for WinRT on Windows Phone 8.1 in the WinRT.Phone project. This also means you can use the new Universal solution/project type to build WinRT apps for Windows 8.1 and Windows Phone 8.1.

This prerelease also includes the new HttpProxy/Host and BrokeredProxy/Host data portal channels.

The Http data portal channel allows you to host the data portal server directly in ASP.NET MVC 4 or MVC 5 without the need for WCF. It relies only on the HttpClient library to invoke the server, so the client has no dependency on WCF - important for the new Windows Phone 8.1 programming model where WCF doesn't exist.

The Brokered data portal channel allows you to host the data portal server in .NET as a brokered assembly, thus available to a WinRT client app. This means you can build a WinRT app that makes data portal calls, where the "server-side" code is also running on the client device, but has access to full .NET. This will only work on Intel-based devices where full .NET assemblies can be deployed. It will only work with side-loaded apps, not apps from the Windows Store.

This is cool – Visual Studio Live! is coming to Washington D.C. this October.

This is the first time the conference has been in D.C. and I’m personally quite excited – not only by the chance to talk to a bunch of enthusiastic technologists from all over the world, but also because I’ll be in D.C. and can take a little time to see some of the monuments and museums.

What a great opportunity!

You can save $400 off the 5 day all-access Best Value Conference Package by registering here with priority code DCSPK17.

As per my previous post, I’ll also be speaking in Redmond this summer. So whether you attend in the summer on the west coast, or the fall on the east coast I look forward to seeing you!

I thought you might be interested to know that I’ll be speaking at Visual Studio Live!, August 18-22 in Redmond, WA http://bit.ly/RDSPK18 . Join us on this special journey to explore topics covering all-things WCF, ALM, Web Development, Data Management, Visual Studio and more!

I’ll be presenting the following sessions:

Leveraging Windows Azure websites What’s new in WinRT Development

SPECIAL OFFER: As a speaker, I can extend $500 savings on the 5-day package. Register here: http://bit.ly/RDSPK18Reg_ and use code RDSPK18

Learn how you can build better applications at Visual Studio Live! Redmond — bring the development issues that keep you up at night and prepare to leave this event with the answers, guidance and training you need. Register now: http://bit.ly/RDSPK18Reg_

I just had an odd thing happen – the Windows Store app (the store itself) crashed and wouldn’t start, even after a reboot. I’d click the tile and the app would show its launch screen with the busy animation. Task manager showed that it was consuming around half my total CPU time.

I found lots of different possible solutions by searching. From the comments it sounds like some of them fix the issue for some people. None of them (even some wacky ones like enabling Hyper-V) worked for me.

The primary solution appears to be running the Apps troubleshooter. And this did find an issue with the store and it reset the store cache (or tried anyway).

I think (though I’m not sure) that this is the same as running the wsreset.exe utility that is supposed to reset the store’s cache and launch the store.

Neither of those solutions worked.

So I thought if the cache was the problem perhaps I should just clear the cache myself. The cache for the store is located at

We are having this interesting discussion on yammer in Magenic about tech companies and how they compete in the current rapidly changing landscape. Here’s my response to a question about Microsoft’s competitive strategy in a world of Modern App development:

I think we're seeing a number of clear strategies from Microsoft.

1. Release key apps for every major platform - Office for iPad, Skype, Lync are examples - so users get the Microsoft apps they rely on even if they aren't on a Microsoft device – there’s a truism that people don’t buy computers or operating systems (or devices) – they buy machines that run useful apps – software is king, and Microsoft has some of the best software out there

2. Create the most compelling cloud services offering to users - outlook.com, OneDrive, etc. Notice that there are first-class OneDrive and OneNote apps for OS X and iOS for example. As someone who leverages all these cloud services, I find them to be extremely compelling – much in the same way Office is compelling – because they all play so well together as a unified family

3. Create a new device segment via Surface, where users get the productivity of a laptop with the pleasurable leisure experience of a tablet - for my part the Surface is _exactly_ what I've always wanted, because it is my dev machine _and_ I can watch movies on the plane even if the person in front of me reclines their seat

4. Create a comprehensive cross-platform tooling strategy - by partnering with Xamarin (and now with Cordova support) and building out their JavaScript/TypeScript capabilities Microsoft is making it pretty darned easy to build .NET or js apps in Visual Studio that target every platform. This is to their benefit because there are still more Windows devices on the planet than any thing else (if you count all the desktops/laptops that run virtually every enterprise out there) and if they can keep us all building the same software for Windows as everything else then (even in the worst case) inertia works in their favor

5. Leveraging their patent portfolio - like 'em or hate 'em, patents are a real thing, and Microsoft makes around $8-$10 per Android device and I believe some off each iDevice too - and now they are giving Windows away for free for devices under 7" 9”, so Windows is now the cheapest mainstream phone OS on the planet

6. Create the most comprehensive PaaS offering for cloud development - notice that Azure is not only amazingly compelling for .NET developers, but also for HTML 5/Java/PHP/etc. Even if they were to entirely lose the client they have a good shot at being the dominant, or certainly one of the dominant, cloud and server development targets in the foreseeable future

As well all know, portable class libraries are pretty cool, but are restricted by the “lowest common denominator” effect.

For example, CSLA .NET supports the use of DataAnnotations along with the richer CSLA rules engine.

In trying to create one of the new “Universal PCL” assemblies to support WinRT on Win8 and WP8 I ran into the fact that WP8 doesn’t support DataAnnotations.

“No problem” I thought, “we already have our own implementation for WP8 Silverlight, for Android, and for iOS. I’ll just use that code.”

Which worked insofar as that I have a Universal PCL Csla.dll that builds.

But it doesn’t work because I can’t actually use that Csla.dll from WinRT on Win8 because that WinRT already has DataAnnotations and so there are type collisions.

As a result it isn’t clear to me that I can actually create a Universal PCL for CSLA – at least not one that supports DataAnnotations across all platforms like I’m able to do if I create one assembly per target platform (like I’ve been doing since 2007 with Silverlight 2).

I guess this makes sense. The guidance around creating a PCL is that you have code that is simple enough that it doesn’t include any platform-specific implementations that would be solved easily using #if directives. The internal implementation of some parts of CSLA is far from simple, and we do use #if directives to optimize for and/or leverage features of each of the 9 platforms currently supported by CSLA (yes, we really provide business code portability across NINE different platforms).

My personal feeling is that I’d rather support all 9 platforms as efficiently as possible, rather than compromise one or more of them just to use a fancy and optional new concept like the Universal PCL.

(of course if Microsoft and Xamarin add DataAnnotations to Windows Phone 8.1, Android, and iOS then I wouldn’t need to implement it in CSLA and that would also solve this problem – so maybe someday :) )