From around 1995 until 2010 there was really only one operating system for client computing: Windows.

Prior to 1995 there were a lot of options, though most not recognizable to users today: 3270 terminals, VT terminals, OS/2, Windows, DOS, CPM, and a bunch of others. Now most of these weren’t “client computing”, they were relatively dumb terminal technologies that provided access to a server (back then called a mainframe or minicomputer). Very much like today’s web browser (sans JavaScript).

Today we’ve returned to a chaotic landscape of client computing: browsers, Windows, iOS, OS X, Android, Linux (for the daring), and of course it isn’t like the pre-1995 technologies went away, they are just mostly emulated in Windows. What is interesting though, is that most of today’s client computing technologies do actually enable smart client software development. This includes the browser which can be used as a smart client technology via JavaScript development, even though the majority of browser “apps” are actually just colorful versions of 1990-era terminal-based computing where the processing is all on a server/mainframe/minicomputer/whatever-you-want-to-call-it.

What is interesting about this return to client-side chaos is that it has reopened the door for third party developer tools as a niche market.

In the early 1990’s there were quite a number of companies selling developer tools for other company’s platforms. Borland with C++, Delphi and TurboPascal, Gupta with SqlWindows, Powerbuilder, and a lot more.

When Windows became the dominant client computing platform most of these dev tools fell by the wayside (not that they went away, they just stopped being mainstream). This was because they couldn’t compete with Microsoft’s dev tools, which were always in sync with the platform in a way that was probably too expensive for third parties to match.

I think it is notable that our return to client computing chaos (or pluralism?) today has already led to numerous third party dev tool vendors that sell dev tools for other company’s platforms. Xamarin, PhoneGap, Telerik’s tools, and a lot more.

What is different to me is that in the early 1990’s I thought it was pretty obvious that Windows would become a dominant platform, and I tended to argue against using third party dev tools because I thought they’d have a rough go of it. As cool as Delphi was, I always recommended VB.

Today I’m not so sure. I don’t see any of today’s platforms becoming dominant in the foreseeable future. It is hard to imagine Windows returning to its monopoly status, but I can’t imagine iOS or Android or OS X displacing Windows as the primary corporate desktop computing environment either.

As a result we business developers need some way to build software independently of any particular platform or OS vendor, because we must assume all our business software will need to run on multiple platforms and OSes.

So today I find myself in the inverse of my early 1990’s stance, in that I’m reasonably convinced that building smart client software (at least for business) means using third party dev tools from vendors that aren’t tied to any one platform.

Of course I’ve spent the last 14 years in the .NET world, so naturally I gravitate toward a combination of Xamarin and Microsoft .NET as a way to use my C# and .NET knowledge across all platforms. I get to develop in Visual Studio on Windows where I’m most comfortable, and my resulting software runs on Android and iOS as well as on Windows Desktop, Phone, and WinRT.

As far into the future as I can see there’s no obvious platform/OS “winner”, so as a developer the question isn’t which platform to target, it is which third party dev tool reaches all platforms with a solid strategy that will stand out and thrive over the next many years.

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