Rockford Lhotka's Blog

Home | | CSLA .NET

 Monday, July 14, 2014

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.

Monday, July 14, 2014 1:00:31 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, July 1, 2014

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: 

    public async Task SaveData()
      if (this.IsDataLoaded)
        var webClient = new HttpClient();
        var data = JsonConvert.SerializeObject(this.Speaker);
#if ANDROID || __ANDROID__ || __IOS__
        var content = new StringContent(data, System.Text.Encoding.UTF8, "application/json");
        var content = new HttpStringContent(data);
        var urlString = apiSpeakerUrl + @"/" + this.Speaker.Id.ToString();
        var response = await webClient.PutAsync(new Uri(urlString), content);
        if (!response.IsSuccessStatusCode)
          throw new Exception("SaveData failed");

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)

CSLA .NET | WinRT | WP8 | Xamarin
Tuesday, July 1, 2014 3:32:53 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, June 18, 2014

csla win8_full This release adds the following key features:

  1. Support for iOS
  2. Support for WinRT on Windows Phone 8.1
  3. Support for Universal Apps that target WinRT on Windows 8.1 and Windows Phone 8.1
  4. A new HttpProxy/Host data portal channel that doesn't rely on WCF
  5. A new BrokeredProxy/Host data portal channel that allows a WinRT (Win8) app to call a local data portal running in full .NET

Here is the version 4.5.600 change log.

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.

CSLA .NET | WinRT | WP8 | Xamarin
Wednesday, June 18, 2014 2:34:52 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, April 28, 2014

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 :) )

Monday, April 28, 2014 2:07:47 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, April 24, 2014

Ho hum. Microsoft is going to bring back the start menu in Windows 8 – presumably in August.Windows-8-logo

That might be ok, though I’ve long since adapted to the start screen so I’m not sure I care at all.

What I do care about are much more real challenges when working in the ‘modern’ or WinRT (Windows Runtime or Windows Store) side of the operating system.

My top list:

  1. The file save/open dialogs don’t sort or filter items and so are almost useless if you have a lot of files
  2. The file save/open dialogs (and OneNote app) often don’t show the full filename or properties of files, making similar files hard to distinguish – again making these core aspects of the OS extremely challenging if not useless
  3. The OneDrive app doesn’t let me access folders shared to me by other people – a feature I use constantly, and so spend more time in the web UI than the app
  4. Unpredictability and lack of control about how WinRT apps display side-by-side is a continual thorn in my side – I launch an app in one monitor and it messes up the display in another monitor? Seriously?!?!
  5. The Calendar app is lame at best. It has some good features, but wastes amazing amounts of space and lacks simple bits of functionality like copying an item or moving an item from one calendar to another. Hopefully it turns into something more like the Windows Phone 8.1 calendar
  6. There’s no way to schedule Lync meetings using the Lync app – how lame is that???
  7. I’ve tried nearly all the file manager apps out there, and some are not bad, but what I _don’t_ understand is why the OneDrive app (which already does OneDrive and local PC stuff) doesn’t just handle things like removable and network drives so it would literally be the “one drive” app
  8. I want a notification summary screen like we now have in Windows Phone 8.1 - _that_ is a useful feature!

I guess what I’m getting at is that I understand that Microsoft feels like they need to add back the Start menu to lure stubborn people into using Win8. BUT what I’m afraid will happen is that they’ll lure people into the WinRT world only to have those people suffer the same day-to-day frustrations I already suffer because these core fit-and-finish capabilities aren’t implemented or complete.

Personally I think it would be better to make the WinRT platform so nice and compelling and fun to use that people will _choose_ to use it over the legacy Desktop with or without cosmetic stuff like a Start menu.

Thursday, April 24, 2014 9:58:09 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, April 3, 2014

Microsoft has substantially improved the story around side loading of Windows 8 WinRT (Windows Runtime or Windows Store) apps for the enterprise and business environments.

I’ve blogged pretty extensively in the past about the costs of the two steps necessary to side load apps:

  1. Unlock your devices for side loading
  2. Actually side load (install) your various business apps

Microsoft has now radically changed the cost of step 1. This blog post from Microsoft contains the following statement:

Enterprise Sideloading– In May, we will grant Enterprise Sideloading rights to organizations in certain Volume License programs, regardless of what product they purchase, at no additional cost. Other customers who want to deploy custom line-of-business Windows 8.1 apps can purchase Enterprise Sideloading rights for an unlimited number of devices through Volume Licensing at approximately $100. For additional information on sideloading licensing, review the Windows Volume Licensing Guide.

Basically what this means is the following (as I understand it):

For developers/testers things are unchanged – you still use a free dev unlock key to install apps for development and testing.

For organizations with an Enterprise Agreement (EA) you’ll be able to get a side loading unlock key that you can use on all your Windows 8 Pro and Windows 8 Enterprise devices, regardless of whether they are domain joined or not. As before, you can also get ‘companion device’ keys to unlock Windows RT devices if you have a Windows 8 Enterprise device too.

For smaller organizations that don’t have an EA you might have (or can get) one of a number of ‘Open’ or ‘Select’ license agreements with Microsoft. Once you have one of these you can buy a side loading key for around $100 that will unlock any number of Windows 8 Pro or Windows 8 Enterprise devices.

When compared to the old model of buying keys for $30/device this is a major change in the right direction. For a maximum of around $100 virtually every organization (small to huge) can get a side loading unlock key for all their devices.

Now this still doesn’t address the need to actually install your apps onto your devices.

Microsoft offers InTune, which is a full MDM (mobile device management) product. If you find the value proposition of an MDM compelling then InTune is probably the right answer for you – though there’s a per device/per month cost (ranging from $6/device/month to $11/device/month) so you don’t get MDM for free of course.

Screenshot (5)I’ve been coordinating an open source project called OrgPortal that you can use to (relatively) easily create an app store for your organization.

There’s another open source project called CompanyStore that is very similar.

Alternately you can have your users manually run a PowerShell to install and update each app manually over time.

I think Microsoft has taken a substantial step in the right direction with the changes to the cost and availability of side loading keys. Couple this with the increasing maturity of projects like OrgPortal and CompanyStore and I think we’re getting to the point where WinRT is something to consider for business app development.

Thursday, April 3, 2014 12:43:38 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Sunday, March 2, 2014

In my last post my focus was on listing the numerous WinRT apps I use on a regular basis – many of which, if I couldn’t get them on Win8 would drive me to carry an iPad. I’m personally not just a software developer, I’m a user of computing as well.

One line, a sensation-maker, in my post was that I think Windows developers who aren’t using WinRT apps are doing their ultimate users a disservice. This doesn’t apply to web developers or other people who aren’t developing actual Windows applications, but it surely applies to people living today in the legacy WPF, SL, and Windows Forms technologies.

The thing is, I made no effort to describe why I believe that to be true, because the focus of that post was to list useful apps.

So what did I mean by that comment?

Here’s the thing. As someone who does use a lot of WinRT apps I can say that a lot of them suck. I’ve divided the suckage into three categories.

Some apps are obviously built by pure mobile developers, who have no comprehension of keyboard/mouse or productivity on anything but a tablet. So their apps are sometimes pretty good on a tablet, but are virtually useless on a laptop or desktop. Because I use all three types of device with pretty much every app, I find that these mobile-only or mobile-first apps just suck. I might use them on my tablet, but they are always pretty secondary to more complete apps because they aren’t universal.

Other apps are obviously built by pure desktop developers, who have no comprehension of touch. These apps often work pretty well with keyboard/mouse, but are awkward to use with touch. Technically they work on my tablet, but they aren’t fun or efficient, and so I consider them to suck.

The third group of sucky apps are built by people with no WinRT user experience. These apps might, in theory, work pretty well with touch and/or keyboard and mouse, but they miss the point of all the cool WinRT features. They don’t use AppBars or the Share charm or Settings or Search correctly. They don’t use dialogs correctly, they don’t use navigation correctly. I’m sure the authors of these apps often think they are being clever by inventing their own techniques, but as a user their apps just suck because they don’t work right.

In short, sucky apps come from three sources:

  1. Mobile developers who don’t consider laptop/desktop device scenarios
  2. Desktop developers who don’t consider tablet scenarios
  3. Developers who are ignorant about the WinRT environment and don’t understand how it works

So as a developer, if you plan to ever build WinRT apps and you aren’t using WinRT then you are pretty much guaranteed to fall into category 3, and very possibly 1 and/or 2.

Hence, if you are a smart client developer – unless you are planning to retire on WPF (which is fine) or switch to the iPad/Android world, you are doing yourself and your users a disservice if you aren’t actually using and learning “the WinRT way”.


Jason Bock mentioned something to me that got me thinking. I base all of this on one core assumption:

Win32 has no long-term future as a mainstream technology.

To be clear, I am 100% sure Win32 will be around for the next 20-30 years, just like mainframes and minicomputers are still with us – usually hidden behind the scenes or in a terminal window, but still here. I don’t think anyone would call them “mainstream” though. Nobody ever mentions IBM in the same breath as Microsoft/Apple/Google/Samsung.

Now if you think Microsoft will back off from WinRT, and by some miracle Apple and Google and Samsung will just completely fail to adapt iOS, Android, or ChromeOS to the enterprise, then you can imagine yourself still doing Win32 as a mainstream technology in 5-7 years.

I personally can’t imagine that happening. I think 5 years from now Win32 will be pretty much what we think of as VB6 today. Something that runs a ton of software, and something that people still do, but not something that would be considered mainstream or vibrant.

For my part, I think that if Microsoft does back off WinRT to try and rejuvenate Win32 … well … that’ll be the opening one or more competitors needs to swoop in and take the enterprise desktop.

Sunday, March 2, 2014 10:55:12 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, February 26, 2014

New Skitch I thought I’d post a list of the top Windows 8 WinRT (windows store) apps that I use all the time.

I know a lot of people who are running Win8 and treating it like Win7 – never leaving the legacy Desktop if at all possible. I think those people are doing themselves a disservice, and in the long run if they are developers then they are doing their users a disservice. I say this because I view the Desktop today in the same light I viewed green screen terminals in the early 1990s – a necessary evil that will ultimately fade into the mists of time (except for those poor users who will forever be stuck using legacy apps).

So these are the apps that, if they didn’t run on Win8, would probably drive me to get an iPad or Android tablet (except that because they are on Win8 I can use them on my tablet AND on my desktop, which is extremely nice). For the most part these are pinned on my start screen on my tablet and desktop. I’ve bolded the WinRT apps and left the legacy Desktop apps unbolded so it is clear just how much I use WinRT.


  • Mail, Calendar, People – the standard apps/hubs that come with Win8 – they started out bad, but have become quite good
  • Outlook (desktop) – I only use this to schedule Lync meetings anymore, but can’t live without it until there’s an alternative way to schedule a Lync meeting
  • Yahoo Mail – I use yahoo as my spam dump, but occasionally scan through to see if anything real creeps into that mail box
  • OneNote – they’ve really made this app nice for keyboard/mouse and touch and pen users – indispensible!
  • Skitch Touch – nice, easy to use graphic editor – I use it to crop/annotate quick screen grabs for the most part
  • Healthvault – keep track of my blood pressure and weight, important given my recent health issues, and it works on WP8 too
  • qool – a very simple to-do tracker, which works for me because it is low-friction, but I wish it worked on WP8 too
  • MyTrips – I travel a lot and rely on to keep me sane; MyTrips is on Win8 and WP8 and is better than the “official” Tripit app
  • Office (desktop) – I so wish there was a WinRT version of Office, but in the meantime I can’t live without the legacy Desktop version
  • Live Writer (desktop) – still the best way I know to author blog posts

News, weather, etc:

  • Nextgen Reader – RSS reader that also runs (and syncs) to my WP8 phone
  • Bing News, Bing Weather – nice apps, consistent on WP8 (finally), and keep me up to date with the world
  • MyRadar – consistent with WP8 and the fastest way to get weather radar on any device – I love this app!
  • Reading List – keeps a list of articles/posts/URLs that I want to review or use later
  • Flipboard – I use this only on my tablet because it is only fun with touch, but it presents a visually pleasing way to browse facebook/twitter/other web info


  • Bing Finance – keep track of the market and business news
  • Mint – keep track of family finances – mostly just trying it out (and it is really nice), because I’m already a Quicken user
  • Quicken (desktop) – keep track of family and business finances, but I wish there was a WinRT version more like Mint – my problem is that Mint can’t do small business stuff, so I need Quicken


  • Lync (desktop) – I mostly use the Desktop version, though the WinRT app is slowly catching up and I do look forward to being able to use it
  • Twitter – the official twitter app, I’m sure there are better ones, but I’m not a heavy twitter user so this is fine
  • Skype – I use the WinRT app, but sometimes I also use the Desktop app – but the WinRT app is catching up fast, which makes me happy
  • Facebook – sure I can get there via the web, but I do like the app
  • Yammer – I mostly use the web because the yammer app is pretty poor, but it works as a share target; the WP8 app is better
  • Reddit by samrad – I’m not a big reddit user, but this is a nicely designed app that is fun to use
  • IE11 – for LinkedIn, because they don’t have an app yet; and for yammer because the WinRT yammer app is too limited


  • Xbox Music – I have a subscription to the service, and love the access to so much music on my tablet/PC/phone
  • Xbox Video – I’ve purchased a few movies to watch on the airplane on my Surface, and we also watch them on the TV through the Xbox
  • Netflix – we cut the cable a couple years ago and rely on Netflix/Hulu/Amazon for almost all media, so this app is indispensible
  • Hulu Plus – see my notes on Netflix – indispensible
  • IE11 – I wish, oh do I wish, that Amazon had streaming video app, but as it is I’m stuck using IE to watch Amazon video
  • MetroTube – very nice youtube app; another is MegaTube, but personally I prefer MetroTube
  • Zune (desktop) – my Xbox Music subscription provides me with 10 free songs each month, and the old Zune app is the only way to use those 10 credits to ‘purchase’ the tracks
  • Comics – the Comixology app is really nice; I know, as an adult I shouldn’t read comics, but I’m an uber-geek so I do, and this app is a really nice way to read them
  • Kindle – I mostly use a real Kindle because I don’t like reading on a glossy screen, but if I’m caught without my Kindle I’ll read on my Surface or phone
  • VEVO – I remember the days when MTV used to be about music videos, and VEVO is much like MTV from 1985 – happiness!


  • Clipboard – this is an app that allows you to Share from any app into the Windows clipboard, and I use it constantly – couldn’t live without it
  • File Manager HD – the best file manager app I’ve found so far – local and remote file access, quite nice
  • OneDrive/SkyDrive – slightly faster than File Manager HD for OneDrive access, but otherwise a duplicate
  • Dropbox – gives access to shared folders and other advanced features not in File Manager HD
  • Box – really a duplicate of File Manager HD
  • Remote Desktop – the WinRT Microsoft RDP client is nice, and I use it daily
  • TeamViewer – I sometimes use TeamViewer to connect to my desktop when I’m on the road; not as fast/smooth as RDP, but it gets through firewalls and NAT routers better


  • Photos – I do use this app, but it was far better in Win8 than it is in 8.1 – they really crippled it…
  • Live Photo Gallery (desktop) – The only way to get at the thousands of photos on my server, and remains far, far more powerful than the built-in Photos app


  • Steam (desktop) – so I can get at all the games I’ve purchased via Steam
  • Origin (desktop) – so I can play Battlefield 4 and (soon) TitanFall
  • Wordament – my favorite casual game
  • Halo Spartan Assault – so nicely done, and fun to play


  • Amazon – of course! I do more shopping on Amazon than pretty much anywhere else
  • – I’m not a small man, and zappos always has shoes that fit, and their service is excellent
  • NewEgg – I go back and forth between their app and their web site, but the app is pretty decent


  • Visual Studio (desktop) – of course
  • Blend (desktop) – of course
  • Xamarin Tools (desktop) – build iOS and Android apps with C#, what more could you want???
  • GitHub for Windows (desktop) – nice way to interact with github and Visual Studio Online repositories
  • TortoiseGit (desktop) – I used TortoiseCvs, then TortoiseSvn, so it is natural that I’d use TortoiseGit more than any other git client
  • Windows 8 Dev Icons – provides useful icons with code snippets to access them
  • Xaml Candy – provides useful code snippets for common XAML elements
  • Samples Browser – browse Microsoft samples
  • Code Writer – a nice WinRT text/code editor for numerous file formats
  • Project Spark – so much fun to build WinRT and Xbox games
  • Project Siena – has the potential to be the “VB” of WinRT if they continue to evolve this tool – there’s no faster way to build simple WinRT business apps
  • Chrome (desktop) – for when IE11 doesn’t meet my needs
Windows 8 | WinRT | WP8
Wednesday, February 26, 2014 11:28:46 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, October 7, 2013

The short answer to the question of whether the Microsoft .NET Framework (and its related tools and technologies) has a future is of course, don’t be silly.

The reality is that successful technologies take years, usually decades, perhaps longer, to fade away. Most people would be shocked at how much of the world runs on RPG, COBOL, FORTRAN, C, and C++ – all languages that became obsolete decades ago. Software written in these languages runs on mainframes and minicomputers (also obsolete decades ago) as well as more modern hardware in some cases. Of course in reality mainframes and minicomputers are still manufactured, so perhaps they aren’t technically “obsolete” except in our minds.

It is reasonable to assume that .NET (and Java) along with their primary platforms (Windows and Unix/Linux) will follow those older languages into the misty twilight of time. And that such a thing will take years, most likely decades, perhaps longer, to occur.

I think it is critical to understand that point, because if you’ve built and bet your career on .NET or Java it is good to know that nothing is really forcing you to give them up. Although your chosen technology is already losing (or has lost) its trendiness, and will eventually become extremely obscure, it is a pretty safe bet that you’ll always have work. Even better, odds are good that your skills will become sharply more valuable over time as knowledgeable .NET/Java resources become more rare.

Alternately you may choose some trendier alternative; the only seemingly viable candidate being JavaScript or its spawn such as CoffeeScript or TypeScript.

How will this fading of .NET/Java technology relevance occur?

To answer I’ll subdivide the software world into two parts: client devices and servers.

Client Devices

On client devices (PCs, laptops, ultrabooks, tablets, phones, etc.) I feel the need to further split into two parts: consumer apps and business apps. Yes, I know that people seem to think there’s no difference, but as I’ve said before, I think there’s an important economic distinction between the consumer and business apps.

Consumer Apps

Consumer apps are driven by a set of economic factors that make it well worth the investment to build native apps for every platform. In this environment Objective C, Java, and .NET (along with C++) all have a bright future.

Perhaps JavaScript will become a contender here, but that presupposes Apple, Google, and Microsoft work to make that possible by undermining their existing proprietary development tooling. There are some strong economic reasons why none of them would want every app on the planet to run equally on every vendor’s device, so this seems unlikely. That said, for reasons I can’t fathom, Microsoft is doing their best to make sure JavaScript really does work well on Windows 8, so perhaps Apple will follow suit and encourage their developers to abandon Objective C in favor of cross-platform JavaScript?

Google already loves the idea of JavaScript and would clearly prefer if we all just wrote every app in JavaScript for Chrome on Android, iOS, and Windows. The only question in my mind is how they will work advertising into all of our Chrome apps in the future?

My interest doesn’t really lie in the consumer app space, as I think relatively few people are going to get rich building casual games, fart apps, metro transit mapping apps, and so forth. From a commercial perspective there is some money to be made building apps for corporations, such as banking apps, brochure-ware apps, travel apps, etc. But even that is a niche market compared to the business app space.

Business Apps

Business apps (apps for use by a business’s employees) are driven by an important economic factor called a natural monopoly. Businesses want software that is built and maintained as cheaply as possible. Rewriting the same app several times to get a “native experience” on numerous operating systems has never been viable, and I can’t see where IT budgets will be expanding to enable such waste in the near future. In other words, businesses are almost certain to continue to build business apps in a single language for a single client platform. For a couple decades this has been Windows, with only a small number of language/tool combinations considered viable (VB, PowerBuilder, .NET).

But today businesses are confronted with pressure to write apps that work on the iPad as well as Windows (and outside the US on Android). The only two options available are to write the app 3+ times or to find some cross-platform technology, such as JavaScript.

The natural monopoly concept creates some tension here.

A business might insist on supporting just one platform, probably Windows. A couple years ago I thought Microsoft’s Windows 8 strategy was to make it realistic for businesses to choose Windows and .NET as this single platform. Sadly they’ve created a side loading cost model that basically blocks WinRT business app deployment, making Windows far less interesting in terms of being the single platform. The only thing Windows has going for it is Microsoft’s legacy monopoly, which will carry them for years, but (barring business-friendly changes to WinRT licensing) is doomed to erode.

You can probably tell I think Microsoft has royally screwed themselves over with their current Windows 8 business app “strategy”. I’ve been one of the loudest and most consistent voices on this issue for the past couple years, but Microsoft appears oblivious to the problem and has shown no signs of even recognizing the problem much less looking at solutions. I’ve come to the conclusion that they expect .NET on the client to fade away, and for Windows to compete as just one of several platforms that can run JavaScript apps. In other words I’ve come to the conclusion that Microsoft is willingly giving up on any sort of technology lock-in or differentiation of the Windows client in terms of business app development. They want us to write cross-platform JavaScript apps, and they simply hope that businesses and end users will choose Windows for other reasons than because the apps only run on Windows.

Perhaps a business would settle on iOS or Android as the “one client platform”, but that poses serious challenges given that virtually all businesses have massive legacies of Windows apps. The only realistic way to switch clients to iOS or Android is to run all those Windows apps on Citrix servers (or equivalent), and to ensure that the client devices have keyboards and mice so users can actually interact with the legacy Windows apps for the next several years/decades. Android probably has a leg up here because most Android devices have USB ports for keyboards/mice, but really neither iOS nor Android have the peripheral or multi-monitor support necessary to truly replace legacy Windows (Win32/.NET).

This leaves us with the idea that businesses won’t choose one platform in the traditional sense, but rather will choose a more abstract runtime: namely JavaScript running in a browser DOM (real or simulated). Today this is pretty hard because of differences between browsers and between browsers on different platforms. JavaScript libraries such as jquery, angular, and many others seek to abstract away those differences, but there’s no doubt that building a JavaScript client app costs more today than building the same app in .NET or some other more mature/consistent technology.

At the same time, only JavaScript really offers any hope of building a client app codebase that can run on iOS, Android, and Windows tablets, ultrabooks. laptops, and PCs. So though it may be more expensive than just writing a .NET app for Windows, JavaScript might be cheaper than rewriting the app 3+ times for iOS, Android, and Windows. And there’s always hope that JavaScript (or its offspring like CoffeScript or TypeScript) will rapidly mature enough to make this “platform” more cost-effective.

I look at JavaScript today much like Visual Basic 3 in the early 1990s (or C in the late 1980s). It is typeless and primitive compared to modern C#/VB or Java. To overcome this it relies on tons of external components (VB had its component model, JavaScript has myriad open source libraries). These third party components change rapidly and with little or no cross-coordination, meaning that you are lucky if you have a stable development target for a few weeks (as opposed to .NET or Java where you could have a stable target for months or years). As a result a lot of the development practices we’ve learned and mastered over the past 20 years are no longer relevant, and new practices must be devised, refined, and taught.

Also we must recognize that JavaScript apps never go into a pure maintenance mode. Browsers and underlying operating systems, along with the numerous open source libraries you must use, are constantly versioning and changing, so you can never stop updating your app codebase to accommodate this changing landscape. If you do stop, you’ll end up where so many businesses are today: trapped on IE6 and Windows XP because nothing they wrote for IE6 can run on any modern browser. We know that is a doomed strategy, so we therefore know that JavaScript apps will require continual rewrites to keep them functional over time.

What I’m getting at here is that businesses have an extremely ugly choice on the client:

  1. Rewrite and maintain every app 3+ times to be native on Windows, iOS, and Android
  2. Absorb the up-front and ongoing cost of building and maintaining apps in cross-platform JavaScript
  3. Select one platform (almost certainly Windows) on which to write all client apps, and require users to use that platform

I think I’ve listed those in order from most to least expensive, though numbers 1 and 2 could be reversed in some cases. I think in all cases it is far cheaper for businesses to do what Delta recently did and just issue Windows devices to their employees, thus allowing them to write, maintain, and support apps on a single, predictable platform.

The thing is that businesses are run by humans, and humans are often highly irrational. People are foolishly enamored of BYOD (bring your own device), which might feel good, but is ultimately expensive and highly problematic. And executives are often the drivers for alternate platforms because they like their cool new gadgets; oblivious to the reality that supporting their latest tech fad (iPad, Android, whatever) might cost the business many thousands (often easily 100’s of thousands) of dollars each year in software development, maintenance, and support costs.

Of course I work for a software development consulting company. Like all such companies we effectively charge by the hour. So from my perspective I’d really prefer if everyone did decide to write all their apps 3+ times, or write them in cross-platform JavaScript. That’s just more work for us, even if objectively it is pretty damn stupid from the perspective of our customers’ software budgets.

Server Software

Servers are a bit simpler than client devices.

The primary technologies used today on servers are .NET and Java. Though as I pointed out at the start of this post, you shouldn’t discount the amount of COBOL, RPG, FORTRAN, and other legacy languages/tools/platforms that make our world function.

Although JavaScript has a nescient presence on the server via tools like node.js, I don’t think any responsible business decision maker is looking at moving away from existing server platform tools in the foreseeable future.

In other words the current 60/40 split (or 50/50, depending on whose numbers you believe) between .NET and Java on the server isn’t likely to change any time soon.

Personally I am loath to give up the idea of a common technology platform between client and server – something provided by VB in the 1990s and .NET over the past 13 years. So if we really do end up writing all our client software in JavaScript I’ll be a strong advocate for things like node.js on the server.

In the mid-1990s it was pretty common to write “middle tier” software in C++ and “client tier” software in PowerBuilder or VB. Having observed such projects and the attendant complexity of having a middle tier dev team who theoretically coordinated with the client dev team, I can say that this isn’t a desirable model. I can’t support the idea of a middle tier in .NET and a client tier in JavaScript, because I can’t see how team dynamics and inter-personal communication capabilities have changed enough (or at all) over the past 15 years such that we should expect any better outcome now than we got back then.

So from a server software perspective I think .NET and Java have a perfectly fine future, because the server-side JavaScript concept is even less mature than client-side JavaScript.

At the same time, I really hope that (if we move to JavaScript on the client) JavaScript matures rapidly on both client and server, eliminating the need for .NET/Java on the server as well as the client.


In the early 1990s I was a VB expert. In fact, I was one of the world’s leading VB champions through the 1990s. So if we are going to select JavaScript as the “one technology to rule them all” I guess I’m OK with going back to something like that world.

I’m not totally OK with it, because I rather enjoy modern C#/VB and .NET. And yes, I could easily ride out the rest of my career on .NET, there’s no doubt in my mind. But I have never in my career been a legacy platform developer, and I can’t imagine working in a stagnant and increasingly irrelevant technology, so I doubt I’ll make that choice – stable though it might be.

Fwiw, I do still think Microsoft has a chance to make Windows 8, WinRT, and .NET a viable business app development target into the future. But their time is running out, and as I said earlier they seem oblivious to the danger (or are perhaps embracing the loss of Windows as the primary app dev target on the client). I would like to see Microsoft wake up and get a clue, resulting in WinRT and .NET being a viable future for business app dev.

Failing that however, we all need to start putting increasing pressure on vendors (commercial and open source) to mature JavaScript, its related libraries and tools, and its offspring such as TypeScript – on both client and server. The status of JavaScript today is too primitive to replace .NET/Java, and if we’re to go down this road a lot of money and effort needs to be expended rapidly to create a stable, predictable, and productive enterprise-level JavaScript app dev platform.

Monday, October 7, 2013 9:24:20 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, July 9, 2013

A lot of people, including myself, felt (feel?) deeply betrayed by Microsoft’s rather abrupt dismissal of what some of us thought was the best client-side dev platform they’ve ever come up with: Silverlight.

Perhaps even more people are worried about the future of WPF in the face of Microsoft’s obvious focus on the new Windows Runtime (WinRT) at the expense of the Desktop (Win32) technologies such as Windows Forms and WPF.

I’m a little more sanguine about this than many people.

I never really bought into the idea of Silverlight as a cross-platform technology. I know, I know, Microsoft made it work on some flavors of OS X. But they didn’t take it to Linux or Android, and Apple blocked them from ever going to the iPad or iPhone. And honestly, you have to follow the money. Companies don’t exist to do good, they exist to make money, and Microsoft didn’t charge for Silverlight and so only stood to lose money by enabling us to build apps that ran on non-Windows devices just as well as Windows devices.

(as an aside, this is why I never get too upset when Google drops yet another free service – the way I look at it is that I’m exploiting the hell out of Google’s free stuff as long as they have it, and when they decide to drop a free service I just have to start paying for something I should have been paying for the entire time (but didn’t have to thanks to Google’s amazing “business” model)).

I did buy into the idea of Silverlight as a much safer and easier-to-deploy way of building Windows smart client apps. So to me the truly sad part about Silverlight going away is that it pushed us back toward creating apps that aren’t as safe (out of the sandbox), and that are slightly harder to deploy (ClickOnce).

Perhaps I’m unusual, but I really do buy into the idea that smart client apps don’t need the ability to reformat people’s hard drives, or alter system files, or snoop through my personal documents without my knowledge. In other words, the full client-side .NET/WPF/Windows Forms/Win32 technology stack just isn’t necessary for 99% of the apps I want to build and/or run, and after a few decades of dealing with viruses and malware and other bad stuff, I’m about ready to be done with it!

So here we site, with Silverlight in maintenance mode so Microsoft will keep it running on their platforms for another decade, but without any real assurance that it will continue to work on the Mac. And frankly I don’t really care, because I always thought the Mac was a lark.

To me where we are is simple:

  • Microsoft is treating all of Win32/.NET on the client as legacy, so Windows Forms, WPF, and Silverlight are in the exact same boat
    • They are all stable (essentially unchanging) into the foreseeable future
    • They are all good/viable Win32/Desktop client technologies
    • They will ultimately fade away
  • Microsoft is putting all their energy/money into rapidly bringing WinRT up to speed
    • Being a fan of “follow the money”, I expect that we’ll all eventually move to WinRT
    • WinRT 8.1 shows some good XAML/C# improvements over 8.0, demonstrating Microsoft’s commitment to making this a viable platform
    • WinRT still has a fundamentally flawed deployment/licensing model for business apps, and until they fix this WinRT is pretty much useless for business
    • WinRT still lags in XAML features behind Silverlight 5, but it is catching up
    • WinRT (like Silverlight) will hopefully never do everything WPF does, because then we’d be back to the same malware hell-hole we’re in with Win32

In short, for everyone wishing and hoping for Microsoft to put more energy/money into WPF (or even more far-fetched into Silverlight) I think the answer is that THEY ARE – but they are doing it via WinRT, by eventually providing a viable XAML/C# platform for business development on Windows that escapes the baggage of legacy Win32/.NET/Desktop.

We just need to do two things

  1. Be patient, because WinRT is a v1 technology and will take a little time to mature
    1. Something I’m not worried about, because most businesses are just now getting to Win7 and won’t go to Win8 for a couple more years, so there’s some time for Microsoft to get their act together
  2. Keep the pressure on Microsoft to bring WinRT to the level we need
    1. In terms of licensing/deployment models
    2. In terms of technology capabilities

Let’s face it. Either Microsoft (with us pushing/prodding/helping) provides a viable WinRT platform for us in the future, or we’d better all start learning JavaScript and/or Objective C…

Tuesday, July 9, 2013 10:58:43 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, July 1, 2013

After having a couple days to collect my thoughts regarding last week’s Build 2013 conference I want to share some of my observations.

First, I left Build happier with Microsoft than I’ve been for a couple years. Not necessarily due to any single thing or announcement, but rather because of the broader thematic reality that Microsoft really is listening (if perhaps grudgingly in some cases) to their customers. And the display of truly amazing, cool, and sexy laptops and tablets running Windows 8 was really something! I was almost literally drooling over some of the machines on display!

Now to summarize some of my thoughts.

The bad:

  1. They didn’t add support for Silverlight in the WinRT browser (not that anyone really thought they would).
  2. They didn’t fix (or even discuss) the nasty business licensing cost issues around side-loading, meaning most businesses will still find WinRT unpalatable as a development target.

The good:

  1. The changes in Windows 8.1 to provide some accommodations for people who are attached to the Start button are quite nice. To be honest, I was pretty skeptical that these changes were just silliness, but having used 8.1 Preview for a few days now I’m sold on my own positive emotional reaction to having the wallpaper the same on the desktop and start screen (though I’m still not booting to desktop, nor do I plan to do so).
  2. The Windows 8.1 changes that bring the start screen experience more in line with Windows Phone are even nicer. The new item selection gesture (tap and hold) and the fact that new apps don’t automatically appear on the start screen (only on the “app apps” screen) are just like the phone, and make the system easier to deal with overall.
  3. The updates to WinRT XAML are extremely welcome – especially around data binding – these are changes I’ll use in CSLA .NET right away.
  4. The added WinRT API capabilities demonstrate Microsoft’s commitment to rapidly maturing what amounts to a Version 1 technology as rapidly as possible.
  5. The fact that Azure had no big announcements, because they’ve been continually releasing their new stuff as it becomes available is wonderful! In fact, this whole “faster release cadence” concept from Windows, Azure, and Visual Studio is (imo) a welcome change, because it means that the overall .NET and Microsoft platform will be far more competitive by being more agile.
  6. There was a serious emphasis on XAML, and most of the JavaScript content was web-focused, not WinRT-focused – and I think this is good because it reflects the reality of the Microsoft developer community. Most of us are .NET/XAML developers and if we’re going to shift to WinRT someday in the future it’ll be via .NET/XAML. For my part, if I’m forced to abandon .NET for JavaScript I’ll learn general JavaScript, not some Microsoft-specific variation or library – but if I see a viable future for .NET in the WinRT world, then I’ll continue to invest in .NET – and this conference was a start on Microsoft’s part toward rebuilding a little trust in the future of .NET.
  7. The new 8” tablet form factor is way nicer than I’d expected. I had a Kindle Fire and ultimately gave it to my son because I already have an eInk Kindle and couldn’t see a good use for the Fire. But an 8” Win8 tablet is a whole different matter, because it runs the Kindle app and it runs Office and WinRT apps so it is immediately useful. The small screen means amazing battery life and light weight, and the ATOM processor means it runs Win32 and WinRT apps – I’m really enjoying this new Acer device!

The neutral:

  1. As I tweeted last week the one recurring bit of feedback I heard from people was disappointment in the lack of WPF announcements or content. I’m not overly concerned about that, because I view Windows Forms, Silverlight, and WPF as all being the same – they are all in maintenance mode and Microsoft is just keeping them running. The same unprecedented stability enjoyed by Windows Forms developers for the past 8 years is now the reality for WPF too. Sure, this might be a little boring to be on an unchanging platform, but the productivity is hard to beat!!
  2. Related to the lack of WPF content I want to suggest a different interpretation. WinRT with .NET/XAML is (imo) the “future of WPF”. What we really need to see is WinRT XAML continuing to rapidly evolve such that it becomes a natural progression to move from WPF/Silverlight to WinRT at some point in the future. I am encouraged by what was presented at Build in terms of the evolution of WinRT XAML, and if that continues I think we’ll find that moving to WinRT will become pretty attractive at some future time.
  3. There was some content on the use of WinRT to create business apps, and that content was welcome. If-and-when Microsoft does fix the side-loading licensing issues so WinRT becomes viable for business use it is nice to know that some serious thought has gone into design and development of business apps on the new platform.

In conclusion, the overall vibe at the conference was positive. Attendees were, from what I could see, enjoying the conference, the content, and the technology. Moreover, I think Microsoft has taken a first small step toward rebuilding their relationship with (what was once) the Microsoft developer community (not that Azure ever lost this rapport, but the Windows client sure did). If they continue to build and foster this rapport I think they can win back some confidence that there’s a future for .NET and/or Windows on the client.

Monday, July 1, 2013 4:14:12 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, May 6, 2013

Mary Jo reports that Windows 8 sales are roughly on par with Windows 7 sales. Which is good news for Windows 8, because Microsoft said (at the time) that Windows 7 was the fastest selling OS to that point.

She also points out that actual usage of Win8 isn’t terribly high at this point – which isn’t at all surprising (see my blog post on if Windows 8 is a success).

The real value of the numbers just provided by Microsoft is that they are an apples to apples comparison between Win7 and Win8, and that they demonstrate that Win8 is following roughly the same track as Win7 in terms of production and sales.

That’s good news, given that Win7 is (by nearly any measure) extremely successful, and is considered by many people to be the best OS Microsoft has released. Windows 8 on an x86 machine can basically be viewed as a faster version of Windows 7, plus the ability to run WinRT apps, and so I pretty much think of Windows 8 as a slight improvement over the already excellent Windows 7.

As Mary Jo notes, we don’t know if the 100 million figure includes Windows RT. At this point I’m not sure if that really matters – at least not from a business app dev perspective. Windows RT can only run WinRT (Windows Runtime) apps, and the WinRT dev platform is too new and immature to risk targeting it when building large enterprise apps (not to mention the side-loading cost issues).

At this point most organizations appear to be building new smart client apps using WPF, and of course they continue to maintain a great many Windows Forms apps. The strength of Windows 8, as I see it, is that it remains an extremely relevant and potent business app platform via its desktop mode, which runs Win32/.NET apps at least as well as its predecessor.

If Microsoft resolves the side-loading cost issues so licensing and deployment becomes reasonable for small, medium, and large organizations I do think WinRT has a reasonable shot at being the successor to Win32/.NET for business developers. In another version or two it should stabilize and mature to the point that it is pretty comparable to WPF, and thus is attractive and useful to C#/XAML developers. That’ll probably take a couple years, which is also the timeframe that corporate IT groups will probably be willing to consider upgrading from Windows 7 to Windows 8.

In summary: good Windows 8 sales today means that betting on WPF for smart client development should be pretty safe, and will hopefully have a decent migration path to WinRT in 2-3 years.

Monday, May 6, 2013 10:30:54 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, March 5, 2013

I’ve now done four posts where I summarize Microsoft’s side-loading licensing scheme in terms of just how it works, what it looks like from various business perspectives, and why I think they have designed this scheme to compete with the wrong target (iPad instead of HTML 5).

  1. Cost to enable side-loading on a Windows 8 device
  2. Windows 8 LOB deployment ‘story’
  3. Perspectives on WinRT app licensing
  4. Windows 8 WinRT sideloading update

If you work for a large enterprise with EA/SA agreements and an IT staff that manages all your domain-joined Windows 8 Enterprise workstations you can probably stop reading now. You are the one demographic that is well-covered by the existing licensing model.

If you are a small or medium business, or an enterprise (such as a franchise or co-op org) where you have lots of non-domain joined machines, machines that run Windows 8 Pro, Windows RT, or the lowly “Windows 8” basic edition, then read on.

After my first four posts I heard from community members and people inside Microsoft – “ok tough guy, you’ve said what’s wrong, now how would you do it right?” (to paraphrase of course Smile ).

My first reaction is that this isn’t my job. If Microsoft wants to make WinRT unpalatable for business developers so we all switch to cross-platform HTML 5/JavaScript (h5js) then who am I to stop them? Besides, don’t they have high-paid experts to figure this stuff out, and so why should I give my thoughts for free?

My second reaction is that from 2001-today I’ve had the pleasure of working with .NET, and these have been the most enjoyable years of my professional career. Although TypeScript appears to offer some reasonable wrapper around the horror that is JavaScript, I’d much prefer it if Microsoft didn’t destroy the idea of building WinRT apps with XAML/C#/VB.

So here are my thoughts – though please keep in mind that I’m not a licensing expert, nor did I stay at a Holiday Inn Express last night.

To be successful, WinRT licensing needs to address its real competitor: h5js and/or WPF+ClickOnce. If WinRT is going to levy an additional licensing cost above those technologies, then WinRT must have commensurate benefits to offset that cost.

What is the cost to deploy an h5js app? Effectively zero, because the app downloads from a web deployment server into a browser. The browsers are all free, there’s no per-workstation license to enable downloading HTML or JavaScript, so the cost is essentially zero.

What is the cost to deploy a WPF app with ClickOnce? Effectively zero, because the app downloads from a deployment server and is installed on the workstation through a standardized ClickOnce client process. No per-workstation license is required – as long as you have a legal copy of the OS, .NET (and thus ClickOne) are free.

I’ve already covered the costs of deploying WinRT apps in the current scheme in my previous blog posts. Those costs can easily add up to thousands or even millions of added dollars – just for the privilege of deploying your own app to your own workstations.

So does WinRT have benefits over h5js or WPF that make it work this added licensing cost? Probably not at this time. It is a version 1 technology and so is less mature than h5js or WPF. Unlike h5js it isn’t cross-platform, and unlike WPF it doesn’t have a simple pre-built deployment technology like ClickOnce. It does have two benefits: WinRT apps can run on ARM devices as well as Intel devices, and WinRT offers a superior model for building touch-enabled apps. I’ll let you decide if those benefits are worth thousands or millions of extra dollars.

Assuming we agree that WinRT isn’t good enough to justify the added licensing fees over its competition, the question becomes how to license WinRT side-loading in a competitive manner.

Microsoft has expressed the (imo) very valid concern that they don’t want to enable the free-for-all side-loading model of the Android world. And I agree – the last thing I want is for my kids to yet again be able to download random software from random locations that are infested with viruses and malware. I really want control over what gets into public stores. I want my software to be vetted when it comes from public locations.

At the same time, I absolutely don’t want added cost or overhead or complexity for apps coming from my corporate marketplaces. I’m in consulting, so the model must allow for Magenic to have a marketplace for our employees, and our consultants must also be able to leverage the marketplaces of our clients so we have access to their apps while we’re working for them.

Thus far I’ve accumulated some requirements:

  1. No per-device licensing fees
  2. One device must be able to access multiple marketplaces
  3. Public marketplaces must be controlled (or perhaps there is just the one Microsoft Store)
  4. People do work from home, where the “Windows 8” edition is most common, so it should support side-loading as well
  5. InTune is a fine idea for deployment, but it shouldn’t be the only option – customized/tailored “marketplace” experiences should be possible

No per-device fees

Let’s start with this requirement. Microsoft doesn’t charge extra for us to use Windows for business, and it makes no sense as to why they think they can charge an extra tax for us to use WinRT for business. This includes discarding the $30/device fee as well as not requiring the InTune per-device/per-month fee.

If InTune has enough other value people will buy it, but h5js and ClickOnce don’t have a monthly fee, so WinRT needs a comparable model.

Multiple marketplaces

As I noted above, employees of a company like Magenic need access to the Magenic marketplace, and to the marketplace of the company(ies) where they are working as consultants. And one would hope we’d have access to the Microsoft Store as well! This implies a way for each device to access multiple “stores” or marketplaces.

Public marketplaces

I’m rather neutral about public marketplaces beyond the Microsoft Store. My only requirement here, is that if Microsoft did allow such a thing to occur then they should be able to revoke any public marketplace’s “license” or “key” if that vendor becomes a source (intentionally or unintentionally) for malware. The bar for any public marketplace should be as high as the Microsoft Store in that regard.

Or perhaps a better solution is to make public stores legally liable for malware. So it becomes possible for me to seek financial or legal recourse if a marketplace allows malware to slip through onto my device?

Work from home

It is patently absurd to think that I can go to Best Buy and purchase a lowly Windows RT tablet and it can side-load business apps, but the most common Windows 8 edition (Windows 8) can’t be used to run my business apps. I can’t envision any justification for this at all, so clearly this just needs to be fixed.

No InTune requirement

I understand the value of InTune – it does a lot of cool stuff, one of which is deployment. But not everyone wants all that other stuff, and making InTune the only real ClickOnce replacement makes WinRT uncompetitive. Again, h5js and ClickOnce have no monthly cost, and WinRT needs a zero cost option as well.

The result

As a result I think the answer is to license deployment servers not client devices.

And for public servers these licenses should be revokable so Microsoft can easily shut down rogue public marketplaces. I’ll leave the public marketplace concept alone for the rest of this discussion, as I’m much more interested in corporate marketplaces.

To make this work for a small business (think 2-500 employees) the cost of a deployment server license/key must be quite low. A 5 person company might spend 10’s or low 100’s of dollars by not beyond that. I can see how Microsoft might want the cost to scale somewhat, so you could envision deployment server licenses working against a “registered device” model. I honestly think Microsoft would be best served by not charging an extra fee, but if they feel they must find a new revenue source perhaps it could work like this:

  • <=100 devices $100
  • <=500 devices $500
  • <=1000 devices $1000

MSDN subscribers should get a <=10 device license as part of their subscription, allowing for software development and testing.

EA/SA customers might get some deployment server license “for free” as part of their negotiated contract.

Interestingly, Windows Phone 8 already has a corporate marketplace concept built into the phone, where you can register your phone with a corporate marketplace. They (to my knowledge) only support one marketplace, but the core idea is there.

To make this work, a server admin must be able to revoke the registration of a client device (employee leaves, device stolen, etc.), and there should probably be a pre-built WinRT app users can run to register their device with a marketplace (perhaps based on access to an appropriate email domain – like WP8 again).

So a Magenic employee would run this WinRT device registration app and enter their email address. Perhaps this causes the marketplace server to send an email to that address with a confirmation hyperlink. The user clicks that hyperlink to confirm and the marketplace completes registration of that device, making the apps in that marketplace available to the end user.


Again, I’m not a licensing expert. I’m simply looking at the competitive landscape and trying to figure out how to make WinRT financially competitive with h5js and WPF+ClickOnce. Assuming that WinRT has no incredible value proposition over its competitors (and I don’t see that it does) then it must provide a cost-comparable licensing/deployment model.

Given that h5js and WPF+ClickOnce have a zero licensing/deployment cost, the goal should be for WinRT apps to have a zero licensing/deployment cost.

At the same time, I surely don’t want public marketplaces to come into being without some substantial recourse and penalty for any such marketplace that becomes a vector for malware.

I think something along the lines of what I’ve proposed here can achieve these goals, and can make WinRT into a viable business development platform in the future. My guess is that Microsoft has a few months, perhaps 18 at most, to make this happen (or at least to lay out a clear roadmap) before business developers really start migrating away from Windows toward h5js in an effort to ensure their careers remain vibrant and healthy.

Tuesday, March 5, 2013 2:33:53 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, February 26, 2013

If you’ve followed my blog recently you know I’ve done a lot of research into the licensing around deployment (side-loading) of business apps on Windows 8 (Windows Runtime aka WinRT).


As a result of this two things have happened.

First, I’ve had some interesting conversations with a few people at Microsoft. Some understand the issue, others just don’t get it. If you think this is an issue I suggest you have conversations with any Microsoft people you know because that’ll help educate and pressure them to fix the problem.

As an aside, it is hard to talk to the right people at Microsoft because the Windows Division owns all this stuff and they don’t talk to developers. In fact, they are almost constantly behind what’s known as the “veil of silence” – essentially unable to discuss anything interesting without risk of being fired. This unwillingness to talk to developers on your own platform is pretty ridiculous, and makes it virtually impossible to generate enthusiasm for building apps on the platform. I have hopes that Sinofsky’s departure from Microsoft will eventually allow them to come to their senses…

Second, I’ve had a number of people ask if I think Windows and/or Microsoft is done for on the client, at least in terms of business software development.

Although I think that’s a very real possibility, given just a bit more maturity in the HTML 5/JavaScript (h5js) space, I don’t think the Windows client is a lost cause yet either.

The thing about the licensing/deployment side-loading story is that Microsoft has it set up to be perfectly acceptable to large enterprises. Those orgs almost certainly already have an EA/SA and use SCCM and run domain-joined Windows Enterprise machines. Their Windows RT or other Win8 mobile devices are covered by the SA and/or companion device licensing. So their only incremental cost is the $4/mo/device InTune cost. That’s extremely comparable to the cost of MDM products for iPad/Android devices.

Where the Microsoft story falls short is in the SMB (small-medium business) space where businesses probably don’t have those bigger contracts and IT infrastructure. That’s where the incremental costs start to add up pretty fast (as per my previous blog posts and Excel cost calculator). Of course the long tail suggests that there are a lot more SMB orgs than enterprise orgs, so the poor story for this segment of the market is pretty devastating.

I keep posting and talking bluntly about the licensing/deployment story because I think we all need to be aware of what’s going on. We all need to know it so we can make near-term decisions regarding the use of WPF, h5js, and/or WinRT. And because those of us who enjoy building smart client Windows apps can pressure Microsoft into fixing the licensing story before it is too late.

Finally, speaking of “too late”, that’s a slippery phrase.

Businesses are mostly just now upgrading to Windows 7, and won’t go to Windows 8 for 2-4 more years. So in a sense you can argue that Microsoft has a lot of time to fix the side-loading story, because almost no one is going to care about this for a long time anyway.

On the other hand, the developer community tends to move a bit faster. We’re a fickle bunch. If we don’t perceive WinRT as a viable future platform for business apps then we’ll start retooling our skills to something else in order to preserve our careers. That won’t take 4 years. I suspect Microsoft has less than 2 years to get developer buy-in to WinRT or the siren call of h5js will become too much to bear.

At the moment of course, h5js has no rational or consistent smart client deployment story either. Although its ability to support smart client business development is maturing pretty fast, the only widespread deployment model still requires a real-time connection from the client device to a web server. Once the industry settles on a way to package and deploy “h5js apps” for offline use (and I believe that _will_ happen) then Microsoft’s ability to generate enthusiasm for WinRT becomes much harder.

I see this as a race. Can Microsoft generate enthusiasm around WinRT in the business developer world (by fixing the side-loading issue and by actually talking to developers at all)? And can they do that faster than the h5js world can devise and settle on a reliable smart client story of their own (because they already have developer enthusiasm).

In short:

  1. Microsoft has the technical issues pretty much solved, but seems intent on alienating business developers.
  2. The h5js world has a lot of developer enthusiasm, but has yet to tackle or solve some critical technical issues

It’ll be fun to see what happens over the next couple years.

h5js | Windows 8 | WinRT
Tuesday, February 26, 2013 12:21:15 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, December 20, 2012

A colleague of mine at Magenic recently posted on how to deploy and debug a WinRT app on a Surface RT.

Another alternative is to install the app onto the Surface device via PowerShell. This won’t attach the debugger, but is often an appropriate solution for people who are just testing the app (QA testers, colleagues willing to provide feedback, etc.).

This is a multi-step process. At a high level it goes like this:

  1. Developer packages the WinRT app to a folder on their hard drive, then puts the package on a network share or USB key, etc.
  2. Tester unlocks PowerShell on their device (this is a one-time thing)
  3. Tester gets the WinRT app package and runs a PowerShell script to install the app on their device

Creating the Package

The developer needs to create a distributable package for the app. This is done by right-clicking on the WinRT project in the Visual Studio solution explorer, and choosing Store –> Create App Packages.


This brings up the Create App Package wizard. The first question is whether you want to deploy the the store, and the answer in this case is No.

Next, you’ll be asked where to create the package, how to create the package version number (different from the app version number) and what platforms to target.


The Neutral architecture in Release (Any CPU) allows testing on Intel and ARM devices.

When the Create button is clicked, the project is built and packaged, with the results placed in the specified folder.


The top level folder contains an appxupload file that you can safely ignore (it is used for uploads to the store). It also contains a sub-folder with the actual app package.


These are the files you must make available to the tester. You can put these files on a network share, a USB key, a SkyDrive folder, or any other location where the tester can gain access. The Add-AppDevPackage.ps1 file is the PowerShell script the tester will run to install the app.

Unlocking PowerShell

The tester’s device must be able to execute PowerShell scripts before they can install the app. By default PowerShell has security settings that prevent scripts from executing. This TechNet article discusses running PowerShell scripts. In summary, you need to open PowerShell as Admin and run this command:

Set-ExecutionPolicy unrestricted

Be aware that this allows execution of any script, so you do assume some risk by enabling this policy.

Once this has been done your test device is now able to install WinRT apps by executing the PowerShell script generated by Visual Studio.

Installing the App

On the test device you must have access to the contents of the package folder created by the developer in Visual Studio. You might get those files from a network share, a USB key, or other location.

Simply execute the Add-AppDevPackage.ps1 file in PowerShell to install the app.

The script will ask permission to run.


If this device does not have a side-loading unlock key (MAK or developer key), you will be asked if you want to get a developer key. You should answer yes and walk through the wizard to get a developer key for this device. This step will require you to enter your Microsoft Account email address and password. The resulting key will expire after a short period of time (currently three months).

The PowerShell script will then ask for permission to install the certificate for the app. If you’ve already installed the certificate (perhaps you are installing a newer version of the same app) the script will skip this step.



Once the certificate is installed, the script will install the WinRT app itself.


At this point the WinRT app is installed and its tile should appear on the start screen along with all other apps installed on this device.

The user may now run the app like any other app.

Once the developer key for this device expires the app will stop working. Obviously the intent of this installation approach isn’t for the user to run the app forever, but rather so they can test it and provide feedback during the development process.

Thursday, December 20, 2012 12:06:59 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, December 7, 2012

The web site is apparently now gone, merged into the broader ecosystem (where it belonged in the first place imo):

As we’ve known now for a long time, Silverlight is “dead”. It is in support mode and will be for a decade.

Just like Windows Forms has been since 2005, and WPF is now as well (do you really think Microsoft is going to divert money from WinRT to do anything with WPF at this point??? If so I’ve got this beachfront property for sale…).

As an aside, ASP.NET Web Forms also “died” in 2005, but recently got a major infusion of money in .NET 4.5 – showing that even a “dead” technology can receive a big cash investment sometimes – though it still isn’t clear that this will be enough to breath any new life into Web Forms for most organizations. I suspect it is more likely that this recent investment will just allow organizations with massive Web Forms sites to keep them limping along for another 5-10 years.

If a technology is defined as “dead” when its vendor stops enhancing it and starts maintaining it while they put most of their money into the future, then I must say that I’ve spent pretty much my entire ~25 year career working on dead technologies. And it has been fun! Smile

Although some of us tech geeks like to jump to the next potential upcoming thing, the people who actually fund software projects rarely want to accept that kind of risk. They generally prefer to build applications on stable technology. Most stable technology is “dead” or “dying” based on this idea of “live” technology being rapidly changing and evolving.

Obviously there’s a fine line here.

Target stable technology that is too old and you really are in trouble. Windows Forms is an example of this, because its underlying technology has no migration path to a WinRT future. Although a lot of organizations have massive investments in Windows Forms, I would hope that they’d shy away from starting new development on this extremely stable, but now too old, technology.

Target stable technology that is new, but old enough to be stable and life is generally pretty good. WPF and Silverlight (for smart clients, not for cross-platform RIA) are examples of this. The reason is that these technologies (especially Silverlight) have a good migration story to a WinRT future. A lot of organizations are investing in WPF, and that’s good. But I’d be shocked if Microsoft invests anything in WPF going forward – its future is the one Windows Forms has enjoyed since 2005 – stable maintenance of the technology. Perfect for building critical business apps. Organizations also have large investments in Silverlight, and as long as the intent was smart client development (not cross-platform RIA) it seems to me that they are in the exact same place as everyone using WPF. Arguably better, because Silverlight is much closer to WinRT than WPF.

If you are using Silverlight for cross-platform rich web development, then I do agree that the news is not good. The current alternative appears to be HTML 5, though it is also clear that this is an expensive alternative with an unsure future. Just like every other silver bullet to write once and run anywhere, I think you have to go into such a venture expecting a lot of cost and pain. There’s no widely successful example in the history of computing that indicates otherwise…

The final option is to target “live” technologies. You know, the ones where vendors are dumping huge amounts of money, and where the technology and platform are changing rapidly. Things like HTML 5 and WinRT are examples of this. As a tech geek I love it when organizations want to do this sort of thing, because the challenge is high and we all get to learn a lot of new stuff. Of course the development costs are also quite high because we’re getting paid to learn this new stuff. And the overall costs for the software are high because the technology/platform isn’t stable and the app probably needs to be rewritten (in whole or part) every few months to deal with platform changes.

Some organizations are willing to accept the costs and inconvenience associated with using “live” technologies. But most organizations don’t have the time or money or risk tolerance, and are far better off targeting “dead” technologies like WPF and Silverlight. They just need to be careful to have strategic migration plans so they can get off those technologies before they reach the point of where Windows Forms is today.

Friday, December 7, 2012 11:23:33 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, November 15, 2012

At a .NET Rocks event a few weeks ago an attendee asked if there would be some add-on to Windows 7 that allowed running WinRT apps.

My answer: Yes! It is called Windows 8  :)

Thursday, November 15, 2012 10:57:19 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, October 24, 2012

I am pleased to announce the final release of CSLA 4 version 4.5 with support for the following platforms:

  • .NET 4.5
  • Windows Runtime (WinRT)
  • .NET 4
  • Silverlight 5

The new release is available via nuget and the CSLA download page.

This release includes a number of important features and changes, including:

  • Support for Windows Runtime (WinRT), so you can simply recompile your existing CSLA .NET business classes for WinRT with little or no changes required to migrate to the new platform
  • Support for the new async and await keywords in .NET 4.5 (and in .NET 4 and SL5 via the async targeting pack)
  • Enhancements to the business rules engine
  • Enhancements to Windows Forms support via the Csla.Windows namespace

The entire CSLA .NET dev team has put a lot of work into this release, and we hope you enjoy it and find it useful!

Wednesday, October 24, 2012 4:00:51 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, October 9, 2012

CSLA 4 version 4.5 supports the async and await keywords across all platforms (WinRT, .NET 4.5, .NET 4, Silverlight 5).

You can use these async features to implement async rules in the CSLA rules engine. Here’s one such rule:

public class CustomRule : Csla.Rules.BusinessRule
  public CustomRule(Csla.Core.IPropertyInfo primaryProperty)
    : base(primaryProperty)
    IsAsync = true;

  protected async override void Execute(Csla.Rules.RuleContext context)
    var cmd = new LongRunningCommand();
    cmd = await DataPortal.ExecuteAsync(cmd);
    context.AddInformationResult("Rule complete: " + cmd.Output);

  public class LongRunningCommand : CommandBase<LongRunningCommand>
    public static readonly PropertyInfo<string> OutputProperty = RegisterProperty<string>(c => c.Output);
    public string Output
      get { return ReadProperty(OutputProperty); }
      private set { LoadProperty(OutputProperty, value); }

    protected new async Task DataPortal_Execute()
      Output = "Before delay";
      await Task.Delay(3000);
      Output = "After delay";

Notice that the rule’s constructor sets the rule’s IsAsync property to true. This tells the CSLA rules engine that the rule will be async.

Also notice that the rule’s Execute method is marked with the async keyword, allowing the use of the await keyword within the method. In this example, the rule uses the data portal to asynchronously execute a command object by awaiting the ExecuteAsync method.

Because the rule has IsAsync true, the Execute method must call context.Complete to indicate that the rule has finished processing. If you don’t call context.Complete the CSLA rule engine will never process the rule’s result, and you’ll have a bug in your application.

The command object itself also uses the async keyword to implement the DataPortal_Execute method. Notice that this method returns a Task. The server-side data portal components are smart enough to detect when a DataPortal_XYZ method returns type Task, so the DataPortal_XYZ method is invoked correctly.

Within the DataPortal_Execute method I just use Task.Delay to create an artificial delay. This represents some long-running operation such as calling a slow web service, invoking an intensive oData query, or something like that.

The end result is that a business object can attach this CustomRule to a property, and the rule will run asynchronously. This is done in the business class’s AddBusinessRules method.

In your UI you can use helper components such as Csla.Xaml.PropertyInfo to determine that the property is running an async rule. For example, you might use XAML like this in WinRT:

<StackPanel Orientation="Horizontal">
  <TextBox Text="{Binding Path=Name, Mode=TwoWay}"/>
  <TextBlock Text="{Binding ElementName=NameInfo,Path=RuleDescription}" Foreground="Yellow"/>
  <ProgressRing IsActive="{Binding ElementName=NameInfo,Path=IsBusy}"/>
  <csla:PropertyInfo Name="NameInfo" Source="{Binding}" Property="Name"/>

The specific XAML syntax is a little different in WPF/Silverlight because the XAML language is more mature there than in WinRT. But the basic concept of building a rich user experience based on an async rule is the same across all smart client platforms.

Tuesday, October 9, 2012 3:59:52 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, September 24, 2012

CSLA 4 version 4.5.2 is now online. This is Beta 1 of the 4.5 release, and is the start of the beta process. I expect to release a number of betas in relatively short order between now and the end of October. My plan is to have a final release before Windows 8 GA.

You can get this beta release from nuget (show unreleased versions), or via the installer from the CSLA download page.

This release supports .NET 4, .NET 4.5, WinRT, and Silverlight 5.

This beta release is a major change over the previous preview releases.

  1. CSLA now fully supports the new WinRT platform for Windows 8 development.
  2. The data portal now supports async/await on the client and on the server. Additionally, the .NET, WinRT, and Silverlight data portal implementations are now the same. There is no longer a “Silverlight data portal”. To make this happen, the data portal pipeline underwent major changes. This includes a number of breaking changes.
  3. The MobileFormatter is now available for use by .NET applications (not just Silverlight and WinRT). This might allow .NET apps to run in partial trust, and certainly allows .NET apps to use the same data portal channel/endpoint  as a WinRT or Silverlight app.
  4. Jonny has done a lot of work on the business rules engine. There shouldn’t be any real breaking changes, but there are a lot of good new features.
  5. BusinessBase metastate properties (such as IsDirty) are now bindable – they raise PropertyChanged as you’d expect. This enables some XAML scenarios, but be careful because WinRT XAML doesn’t notice when the DataContext has changed, so you can run into some strange issues when saving an editable object in WinRT.
  6. Johann put a lot of work into the nuget release process, allowing us to use nuget for prereleases like this one, and to create a nuget package with code templates for use in your projects.
  7. We now support .NET 4.5 and 4.0 with CSLA 4.5, so you can use the same CSLA 4.5 on existing .NET 4 machines, on Windows Azure, and also use it on .NET 4.5 machines. A 4.5 client can talk to a .NET 4 server and visa versa.
  8. WinRT now includes language resources.
  9. A number of changes were made to the Windows Forms CslaActionExtender type.

Be aware that the .NET 4 and Silverlight 5 environments now require that you use the Async Targeting Pack from Microsoft (typically via nuget) so that CSLA and your code can use the async/await keywords and related functionality.

Be aware that the data portal has breaking changes, especially for Silverlight users. Some highlights of breaking changes:

  • The Enterprise Services, Remoting, and asmx data portal channels have been removed. If you need these wire transport technologies you can create your own proxy and host types based on the version 3.8 code (perhaps they’ll end up in CslaContrib at some point).
  • The namespaces for proxy and host types that included “Silverlight” in the namespace now use the term “Mobile” instead. For example, Csla.Server.Hosts.IWcfPortal is now Csla.Server.Hosts.Mobile.IWcfPortal.
  • The client-side ProxyMode concept is now eliminated entirely, and you should use the same RunLocal attribute in Silverlight as you do in .NET.
  • All client-side DataPortal_XYZ methods in Silverlight are now different, and no longer accept a callback handler parameter. Instead, code all client-side DataPortal_XYZ methods for Silverlight just as you would for .NET.

Please direct any comments, suggestions, bug reports, or other feedback to the CSLA forums.

Monday, September 24, 2012 2:16:59 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, August 21, 2012

Most of the work Magenic does for our customers centers around enterprise app development. That’s another way of saying ‘line of business’ or LOB apps in most cases.

Most enterprise and LOB apps will never be placed into the Windows Store for deployment. They’ll typically be deployed from corporate servers to the devices (tablets, ultrabooks, laptops, desktops) of employees. In the mobile world this is called “side-loading”, but that’s just jargon for deploying apps without using a public store.

The Wikipedia page describing the Win8 editions is highly misleading:

If you look at the last item in the comparison grid, it appears that only Windows 8 Enterprise supports side-loading. That is entirely wrong.

The following two links provide important details:

The process for Windows RT (ARM devices) seems to be more polished than for Intel devices, and that is rather strange. But still, Intel devices can be enabled to side-load apps via domain policy or a command line script.

The important thing to understand is that you can side-load enterprise or LOB apps to all editions of Windows 8.

As I’ve said before, if you want to write Windows apps that can run on any Win8 device, you should be targeting WinRT as your development platform.

Tuesday, August 21, 2012 9:35:55 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, August 8, 2012

At Visual Studio Live in Redmond I gave a talk about using SkyDrive and the Windows Live services from WinRT applications.

The LivePush project is here on SkyDrive:

Wednesday, August 8, 2012 8:43:36 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, August 3, 2012

With all the new terminology and conceptual surface area that comes with Windows 8, I think it is important to have some clarity and consistency around the terms and concepts.

Here are some of the basic terms:

  • Windows 8 – the new operating system that runs in a “dual mode”: Desktop (Win32) and WinRT (Windows Runtime)
  • Desktop – the Win32 OS API that supports today’s applications in Win8 (basically Windows 7)
  • WinRT – Windows Runtime: the new OS API that supports “modern” applications
  • Windows RT – Windows 8 on ARM devices (note: Windows RT and WinRT are not the same thing)
  • Windows 8 UI style – a user experience design language often used when building WinRT applications

Windows 8 basically includes two different operating systems.

One is the “old” Win32 OS we think of today as Windows 7. This is now called Windows 8 Desktop, and is available on Windows 8 Intel tablets, laptops, and desktops. This is only partially available on ARM devices, and you should not expect to build or deploy Win32 Desktop apps to ARM devices.

The other is the new Windows Runtime (WinRT) “operating system”. This is a whole new platform for apps, and is available on all Windows 8 machines (ARM, Intel, tablet, laptop, desktop). If you want the widest reach for your apps going forward, you should be building your apps for WinRT.

Confusingly enough, “Windows 8” runs on Intel devices/computers. “Windows RT” is Windows 8 for ARM devices. The only real difference is that Windows RT won’t allow you to deploy Win32 Desktop apps. Windows RT does have a Desktop mode, but only Microsoft apps can run there. Again, if you want to build a Windows 8 app that works on all devices/computers, build the app for WinRT, because it is consistently available.

Windows 8 UI style describes a user experience design language for the look and feel of WinRT apps. This isn’t a technology, it is a set of design principles, concepts, and guidelines.

Another source of confusion is that to build a WinRT app in Visual Studio you need to create a “Windows 8 UI style” app. What makes this odd, is that this type of app is targeting WinRT, and it is entirely up to you to conform to the Windows 8 UI style guidelines as you build the app.

“Windows 8 UI style” was called “Metro style”, but Microsoft has dropped the use of the term “Metro”. I am skeptical that this new “Windows 8 UI style” term will last long-term, because it obviously makes little sense for Windows Phone 8, Xbox, Windows 9, and other future platforms that may use the same UI style. But for now, this appears to be the term Microsoft is using.

Thinking about app development now, there are several options on the Microsoft platforms.

  Technologies Platforms
Full .NET 4.5 ASP.NET, WPF, Windows Forms, WCF, WF Windows 7, Windows 8 Desktop, Windows Server 2008, Windows Server 2012
WinRT .NET 4.5 Windows 8 UI style apps Windows 8 WinRT, Windows Phone 8, rumored for next-gen Xbox
Full .NET 4 ASP.NET, WPF, Windows Forms, WCF, WF Windows 7, Windows Server 2008, Azure PaaS
Silverlight Silverlight Windows 7, Windows 8 Desktop, Windows Phone 7, Windows Phone 8
Friday, August 3, 2012 10:03:20 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, July 30, 2012

I want to summarize some of the more major changes coming to the data portal in CSLA 4 version 4.5. Some of these are breaking changes.

I’ve done four big things with the data portal:

  1. Added support for the new async/await keywords on the client and server
  2. Merged the .NET and Silverlight data portal implementations into a single code base that is now common across WinRT, .NET, and Silverlight
  3. Removed the public virtual DataPortal_XYZ method definitions from Silverlight, because it can now invoke non-public methods just like in .NET. Also, all local Silverlight data portal methods no longer accept the async callback handler, because they now support the async/await pattern
  4. Remove the ProxyMode concept from the Silverlight data portal, because the RunLocal attribute is now available on all platforms

All four have some level of breaking change.

Adding comprehensive support for async/await changes the way .NET handles exceptions. Although I’ve worked to keep the top level exceptions consistent, the actual exception object graph (nested InnerExceptions) will almost certainly be different now.

Merging the .NET and Silverlight data portal implementations introduces a number of relatively minor breaking changes for Silverlight users. Though if you’ve created custom proxy/host pairs or other more advanced scenarios you might be more affected than others. There may also be unintended side-effects to .NET users. Some might be bugs, others might be necessary to achieve platform unification.

Removing the public virtual DataPortal_XYZ methods from BusinessBase and BusinessListBase will break anyone using the local Silverlight data portal. The fix is minor – just change the public scopes to protected. This change shouldn’t affect anyone using .NET, or using a remote data portal from Silverlight.

Removing the async callback parameter from all Silverlight client-side DataPortal_XYZ methods will break anyone using the local Silverlight data portal. The fix is to switch to the new async/await pattern. The code changes are relatively minor, and generally simplify your code, but if you’ve made extensive use of the client-side data portal in Silverlight this will be a pretty big change I’m afraid.

Similarly, removing the ProxyMode concept from the Silverlight data portal is a breaking change for people using the local Silverlight data portal. Again, the fix is pretty simple – just add the RunLocal attribute to the DataPortal_XYZ (or object factory) methods as you have always done in .NET.

On the upside, the coding patterns for writing code in .NET, WinRT, and Silverlight are now the same.

For example, a DataPortal_Fetch method on any platform looks like this:

private void DataPortal_Fetch(int id)

or like this

private async Task DataPortal_Fetch(int id)

The data portal will automatically detect if your method returns a Task and it will await the method, allowing you to use the await keyword inside your DataPortal_XYZ methods.

Similarly, all platforms can now write this client-side code:

var obj = await CustomerEdit.GetCustomerAsync(123);

or the older event-style code:

CustomerEdit.GetCustomer(123, (o, e) =>
      if (e.Error != null)
          throw e.Error;
          obj = e.Object;

Only .NET code can use the synchronous approach:

var obj = CustomerEdit.GetCustomer(123);

This is one of the few platform-specific concepts left in the data portal.

What is really cool is that the client and server sync/async concepts can be mixed (as long as you know what to expect).

Client method Client platform Server method Server platform Remarks
Fetch .NET only void DataPortal_Fetch any Client call is synchronous; server call is synchronous
Fetch .NET only Task DataPortal_Fetch any Client call is synchronous; server call is asynchronous; note that client will block until the server’s work is complete
BeginFetch any void DataPortal_Fetch any Client call is asynchronous (event-based); server call is synchronous; client will not block, and must handle the callback event to be notified when the server call is complete
BeginFetch any Task DataPortal_Fetch any Client call is asynchronous (event-based); server call is asynchronous; client will not block, and must handle the callback event to be notified when the server call is complete
FetchAsync any void DataPortal_Fetch any Client call is asynchronous; server call is synchronous; client will block or not, depending on how you invoke the client-side Task (using await or other techniques); the client-side Task will complete when the server call is complete
FetchAsync any Task DataPortal_Fetch any Client call is asynchronous; server call is asynchronous; client will block or not, depending on how you invoke the client-side Task (using await or other techniques); the client-side Task will complete when the server call is complete

I expect all client-side data portal code to switch to the async/await versions of the methods, and so I’ve made them the mainline path through the data portal. The synchronous and event-based async methods use async/await techniques behind the scenes to do implement the desired behaviors.

There is a lot of variety in how you can invoke an awaitable method like FetchAsync. The specific async behaviors you should expect will vary depending on how you invoke the method. For example, there’s a big difference between using the await keyword or the Result or RunSynchronously methods:

var obj = await CustomerEdit.GetCustomerAsync(123);

var obj = CustomerEdit.GetCustomerAsync(123).Result;

The former is async, the latter is sync. The former will return a simple exception (if one occurs), the latter will return an AggregateException containing the simple exception. This has little to do with CSLA, and nearly everything to do with the way the async/await and task parallel library (TPL) are implemented by .NET.

Finally, I do need to state that the actual network transport (typically WCF) used by .NET, Silverlight, and WinRT aren’t the same. This is because WCF in .NET is far more flexible than in Silverlight or WinRT. And because the WCF client-side proxies generated for Silverlight use event-driven async methods, and in WinRT the proxy is task-based.

The data portal hides these differences pretty effectively, but you should understand that they exist, and as a result there may be subtle behavioral differences between platforms, especially when it comes to exceptions and exception details. The success paths for creating, fetching, updating, and deleting objects are identical, but there may be edge cases where differences exist.

All in all I am quite pleased with how this is turning out. I’ve put a massive amount of work into the data portal for 4.5, especially around unifying the implementations across platforms. I suspect there’ll be some issues to work through during the beta testing phase, but the end result is a far more consistent, maintainable, and streamlined codebase for all platforms. That will benefit all of us over time.

Monday, July 30, 2012 10:53:23 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, July 3, 2012

While the punditry and others are fixated on whether users can adapt to (or even enjoy) the new Windows Start screen and other new UX features, they are missing the real point of Windows 8 and WinRT.

A couple days ago my reasonably computer-savvy son wanted to do some art work, so he downloaded Paint .NET. Or so he thought.

These days most software for Windows is downloaded via the web. And any reasonably popular software has malicious clones with domain names, web sites, and even installers, that look similar to the real thing. This is absolutely the case with Paint .NET.

So my son downloaded what appeared to be a valid installer, from a domain name that seemed reasonable. And just like that his computer was infected with a bunch of Yahoo crap, along with a bunch of real spyware and malware. He’s still trying to get it all cleaned up.

I’ve done the same thing, and I’m extremely computer savvy. Sometimes even the most savvy user gets suckered by a very clever bad guy.

WinRT apps only come from a store. The Microsoft Store, or a corporate “store”.

To get into the Microsoft Store, developers must be registered, apps are screened by Microsoft, and if anything malicious does slip through, the app can be removed/revoked from the store.

To get into a corporate “store”, your employer must choose to put the app into that store. It seems unlikely that your IT department will put apps in their own store that they didn’t create or acquire from a known vendor.

As a result, you can imagine a “Paint WinRT” app that is like Paint .NET, but that my son would have found in the Microsoft Store, and installed from the Store. Effectively zero chance of all the spyware, malware, and Yahoo crap that comes with so much of today’s software.

Now think of all the PC users around the world who will be able to actually find and install software without the fear we all feel in today’s world.

Sure, Win8 and WinRT mean accepting some change. But personally I am entirely ready to embrace that change to get the benefits offered!

Tuesday, July 3, 2012 8:30:53 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, June 18, 2012

This is why I’m putting so much work into making sure CSLA .NET works great on WinRT!

Monday, June 18, 2012 8:19:29 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, May 11, 2012

Unless I’m missing something, there’s no direct way to bind XAML-ish text to a WinRT RichTextBlock control.

For example, if I have some text like:

    This is some text. And some <Bold>bolded text</Bold>.

I would like to just bind this text to a RichTextBlock control for display. Sadly there’s no way to put content into a RichTextBlock control at runtime short of adding Block objects to the control’s Blocks collection.

As a workaround, I’ve been playing with the idea of a custom control like this:

using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Markup;

namespace Application11
  public class RichTextDisplay : ContentControl
    public static readonly DependencyProperty XamlProperty =
        DependencyProperty.Register("Xaml", typeof(string), typeof(RichTextDisplay), new PropertyMetadata(null, XamlChanged));

    public string Xaml
      get { return (string)GetValue(XamlProperty); }
      set { SetValue(XamlProperty, value); }

    private static void XamlChanged(object sender, DependencyPropertyChangedEventArgs e)
      var ctl = (RichTextDisplay)sender;
      var xaml = new System.Text.StringBuilder();
      var text = xaml.ToString();
      var xr = (Control)XamlReader.Load(text);

      ctl.Content = xr;

This isn’t ideal, but it does work. The RichTextDisplay control dynamically creates a RichTextBlock control, inserting the XAML document text into the body of the newly created control.

I suppose the other alternative would be to write code that parses the text to find the XAML elements and produces a series of Block objects that can be added to the control’s Blocks collection…

Friday, May 11, 2012 11:33:13 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, May 7, 2012

There are three fairly popular presentation layer design patterns that I collectively call the “M” patterns: MVC, MVP, and MVVM. This is because they all have an “M” standing for “Model”, plus some other constructs.

The thing with all of these “M” patterns is that for typical developers the patterns are useless without a framework. Using the patterns without a framework almost always leads to confusion, complication, high costs, frustration, and ultimately despair.

These are just patterns after all, not implementations. And they are big, complex patterns that include quite a few concepts that must work together correctly to enable success.

You can’t sew a fancy dress just because you have a pattern. You need appropriate tools, knowledge, and experience. The same is true with these complex “M” patterns.

And if you want to repeat the process of sewing a fancy dress over and over again (efficiently), you need specialized tooling for this purpose. In software terms this is a framework.

Trying to do something like MVVM without a framework is a huge amount of work. Tons of duplicate code, reinventing the wheel, and retraining people to think differently.

At least with a framework you avoid the duplicate code and hopefully don’t have to reinvent the wheel – allowing you to focus on retraining people. The retraining part is generally unavoidable, but a framework provides plumbing code and structure, making the process easier.

You might ask yourself why the MVC pattern only became popular in ASP.NET a few short years ago. The pattern has existed since (at least) the mid-1990’s, and yet few people used it, and even fewer used it successfully. This includes people on other platforms too, at least up to the point that those platforms included well-implemented MVC frameworks.

Strangely, MVC only started to become mainstream in the Microsoft world when ASP.NET MVC showed up. This is a comprehensive framework with tooling integrated into Visual Studio. As a result. typical developers can just build models, views, and controllers. Prior to that point they also had to build everything the MVC framework does – which is a lot of code. And not just a lot of code, but code that has absolutely nothing to do with business value, and only relates to implementation of the pattern itself.

We’re in the same situation today with MVVM in WPF, Silverlight, Windows Phone, and Windows Runtime (WinRT in Windows 8). If you want to do MVVM without a framework, you will have to build everything a framework would do – which is a lot of code that provides absolutely no direct business value.

Typical developers really do want to focus on building models, views, and viewmodels. They don’t want to have to build weak reference based event routers, navigation models, view abstractions, and all the other things a framework must do. In fact, most developers probably can’t build those things, because they aren’t platform/framework wonks. It takes a special kind of passion (or craziness) to learn the deep, highly specialized techniques and tricks necessary to build a framework like this.

What I really wish would happen, is for Microsoft to build an MVVM framework comparable to ASP.NET MVC. Embed it into the .NET/XAML support for WinRT/Metro, and include tooling in VS so we can right-click and add views and viewmodels. Ideally this would be an open, iterative process like ASP.NET MVC has been – so after a few years the framework reflects the smartest thoughts from Microsoft and from the community at large.

In the meantime, Caliburn Micro appears to be the best MVVM framework out there – certainly the most widely used. Probably followed by various implementations using PRISM, and then MVVM Light, and some others.

Monday, May 7, 2012 2:01:55 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, April 26, 2012

I am sometimes asked for technical career advice. A common question these days is whether it is worth learning WPF, or Silverlight – .NET and XAML in general I suppose, or would it be better to learn HTML 5 and JavaScript, or perhaps even Objective C?

This is a challenging question to be sure. How good is your crystal ball? Smile

XAML appears to be alive and well – WPF, Silverlight, and now WinRT (Windows 8 – and probably Windows Phone 8 and “Xbox 720” and more) all use XAML.

I look at the WinRT usage of XAML as being essentially “Silverlight 6” – it is far closer to Silverlight than WPF, but isn’t exactly like Silverlight either. Assuming success with Windows 8, WinRT will become the new primary client dev target for most smart client development (over the next few years).

The primary competitors are Objective C (if you believe iPads will take over the client space), and HTML 5/JavaScript (if you believe in fairy tales the concept of ‘one technology to rule them all’).

This is where the crystal ball comes into play.

Do you think Apple will displace Microsoft – iPads will replace the use of Windows – as the monopoly client OS?

Do you think the concept of ‘natural monopoly’ that has caused the Windows hegemony over the past 20 years is at an end – that some fundamental economic shift has occurred so companies are now willing to increase their IT budgets as a % of revenue to accommodate multiple client platforms (unlike the past 20 years)? In which case business app developers should expect to support at least iPad and Windows, if not Android, into the future?

Do you think that Windows 8 and WinRT will be strong enough to withstand the iPad onslaught, and that the natural monopoly economic effect remains in place, so Windows will remain the dominant client platform for business apps into the foreseeable future?

These are really the three options, resulting in:

  1. Objective C slowly overtakes .NET and we ultimately are Apple devs instead of Microsoft devs
  2. H5/js rules the world as the ‘one technology to rule them all’ and vendors like Microsoft and Apple become entirely irrelevant because we live in a purely open-source world where nobody makes money off any platform technologies, so probably the only hardware/OS left is something like Android running Chrome, because it is a 100% commodity play at that level
  3. .NET and XAML remain entirely valid, and life generally continues like it is today, with a mix of .NET smart client work and primarily server-based web work with h5/js primarily used to boost the user experience, but not often used to write standalone smart client apps

My crystal ball leans toward option 3 – I don’t think economic realities change much or often, and I struggle to see where IT departments will come up with the increased budget (% of revenue) necessary to build apps for both iPads and Windows over the long term. It will be measurably cheaper (by many, many, many thousands of dollars) for companies to buy employees Win8 tablets rather than building and maintaining both iOS and Windows versions of every business app.

And I don’t believe in the ‘one technology to rule them all’ idea. That hasn’t happened in the entire history of computing, and it is hard to imagine everyone on the planet embracing one monoculture for software development. Especially when it would be counter to the interests of every platform vendor out there (Microsoft, Apple, Google, Oracle, and even IBM).

Still with me? Winking smile

To summarize, I think learning XAML is time well spent. Today that’s WPF or Silverlight. There is absolutely no doubt that Silverlight is closer to WinRT than WPF, and people building SL apps today will have an easier time migrating them to WinRT later, whereas most WPF apps will be a pretty big rewrite.

But there’s nothing wrong with focusing yourself on h5/js. If you do so, I suggest doing it in a way that ignores or minimizes all server-side coding. If h5/js does take over the world, it will be used to create pure smart client apps, and if there’s a “web server” involved at all, it will exist purely as a deployment server for the client app. The ‘pure’ h5/js/jquery/etc. world isn’t linked to any vendor – not Microsoft, Apple, or anyone. To me this represents a pretty major career shift, because to truly embrace h5/js as a complete software development platform is so demanding (imo) it won’t leave time to retain .NET or other vendor-specific technology expertise.

For my part, I’m not yet ready to abandon Microsoft for h5/js, because I think Windows 8, WinRT, .NET, and XAML have a rather bright future. A year from now I think a lot of people will be happily using Windows 8 desktops, laptops, and tablets – and hopefully a lot of Windows Phones, and with luck we’ll be looking forward to some cool new Xbox. I live in (I think realistic) hope that my .NET/XAML skills will apply to all these platforms.

What does your crystal ball say?

Thursday, April 26, 2012 9:32:58 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, April 23, 2012

The lack of the BindingExpression type and related functionality in WinRT is a serious issue to anyone trying to create custom controls. Hopefully this issue will be resolved post-beta.

Sadly, the only information I’ve been able to find on this topic from Microsoft is the suggestion to use LostFocus event handlers instead of binding. Obviously that’s a pretty useless workaround when trying to create a custom control Sad smile

I started writing a data binding engine for Android (because they don’t have one at all). It would be a serious shame if we’re forced to write a data binding engine for XAML in WinRT just to be able to implement basic custom control concepts…

Monday, April 23, 2012 4:10:32 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, April 6, 2012

I've been watching a number of discussion threads regarding the usability of Windows 8, especially regarding the start screen, Desktop application usage, and multi-monitor scenarios.

All I can say is don’t knock it until you try it.

I’ve been running Win8 on my tablet and laptop for a few weeks now. The work I do on my laptop is often multi-monitor, and is real work.

There are three themes I’d like to address, based on my full-time usage experience thus far.

First, some people feel that Microsoft is making a mistake by having WinRT (Metro style) and Desktop apps run on the same machine at the same time. I vehemently disagree. I absolutely want one machine that I can use as a tablet on the plane, and as a real computer when I get to my destination. My tablet does this (Samsung from //build/) for almost everything, except when I’m doing distributed computing demos and need my full laptop to run virtual machines (because my laptop has tons of memory and an i7, vs the tablet with less memory and an i5).

I love the fact that I have WinRT apps, which are far superior to most web sites, for consuming news, weather, etc. And I love the fact that the same machine, plugged into a small portable dock, has a keyboard, mouse, second monitor, and can run Visual Studio just fine!

Second, there’s this idea floating around that the Win7 start menu is superior to the new Win8 start screen. That doesn’t hold true for me. Let me explain why.

When I read the Microsoft blog post about the Win7 telemetry data they used to design the start screen, they were describing me. When I use Win7 I pin my common apps and web sites to the start bar, and to run any other apps I press the Windows key and type part of the application name, then press enter. Almost never do I actually use the start menu to browse for apps.

In Win8 (keyboard/mouse – desktop/laptop computer) I pin my common desktop apps to the start bar, and my WinRT apps to the first page or two of the start screen. And I still press the Windows key and type the first part of the application name to run other applications. In other words, THERE IS NO DIFFERENCE between Win7 and Win8 from my perspective – other than that the live tiles from news/weather/stocks/etc. make the start screen a useful dashboard – so it is BETTER than Win7.

(as an aside, I do have some Desktop apps on my start page tiles too – but I find that I rarely use those tiles, preferring instead to tap the Desktop tile and then launch from the start bar – a personal quirk I suppose)

Third, the multi-monitor problems aren’t as bad as they are being portrayed. But the story isn’t good either, and I truly hope it improves over the next few months.

If you are doing “real work” today, you are probably spending 90% of your time (or more) in desktop mode. And if you’ve pinned your common apps to the start bar (like Win7, and I have done this) then you’ll probably never leave desktop mode. And in this case, multi-monitor works just like Win7, but slightly better because the start bar works better in Win8 (or at least it has new options I find useful).

Where the multi-monitor falls down is if you are using a mix of WinRT apps and Desktop applications at the same time.

WinRT only runs on the primary monitor, and that’s just lame. It completely prevents the use of WinRT for many business scenarios where multi-monitor is critical. I honestly don’t expect this to get fixed in WinRT v1, but I hope we don’t have to wait for Windows 9 (2014?) for this to be solved, because it is a major blocker for WinRT development in the real world.

Between the Dev and Consumer previews, they did change the way WinRT apps use the primary monitor. At least now in the Consumer preview it is possible to keep a WinRT app running on the primary monitor while using a Desktop app on other monitors. I do find though, that it is too easy for some errant Desktop app to use the primary monitor, thus making the WinRT app disappear – and this is frustrating.

Sadly it is not possible to keep the start page visible while using a Desktop app on a secondary monitor – reducing its otherwise high value as a dashboard L

To summarize the multi-monitor scenario: if you are a Desktop app user, Win8 is as good or better than Win7, because you’ll only see the start screen when you press the Windows key to launch some non-pinned app. If you are a WinRT user multi-monitor is useless. If you are a hybrid user (like me) the experience is workable, but unpredictable and frustrating.

Clearly Microsoft needs to do more work in this area.

In final summary, don’t knock it until you try it full-time on real machines. The experience overall is quite good, and I VERY much like having WinRT apps that I can use on my main computer instead of using web pages with their inferior usability and aesthetics. Given that most of my main laptop usage is in Visual Studio, Word, and PowerPoint, I find the experience with multi-monitor to be adequate, and Win8 is just as productive for those scenarios as Win7.

Friday, April 6, 2012 9:50:13 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, March 29, 2012

Here are the slides for my Windows Forms to Windows Runtime talk today at Dev Connections.

Thursday, March 29, 2012 10:39:13 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, March 21, 2012

I’ve been spending quite a bit of time working with WinRT over the past couple weeks. Specifically prepping for next week’s Visual Studio Live! and VS Connections conferences.

As part of this process, I have a super early version of CSLA 4 version 4.5 that builds and (mostly) runs on WinRT. I’d done a lot of the work months ago when the Windows 8 developer preview came out, so getting it to work on the consumer preview took only a couple hours.

The only new feature I’ve added so far is support for the new async and await keywords for WinRT data portal code. I still need to add async/await support for the .NET data portal. I might refine some of my implementation, but right now I can use async/await to call the data portal in WinRT, and that’s cool!

The primary observation I want to make right now though, is that business classes created using CSLA 4 that target Silverlight will now recompile for WinRT with no code changes required. I took the entire ProjectTracker business library project and just recompiled it for WinRT and it works – unchanged.

If you want direct reuse of your business logic from .NET/Silverlight to WinRT, you should consider using CSLA 4.

Because I did add the async/await data portal support, I chose to add async factory methods to my business classes, alongside the existing .NET and Silverlight factory methods. From a porting/reuse perspective this is not necessary, but in terms of writing new code for .NET 4.5 and/or WinRT I think we’ll all tend to write these async factory methods.

In short, I added code like this:

    public async static System.Threading.Tasks.Task<ProjectList> GetProjectListAsync()
      return await Csla.DataPortal.FetchAsync<ProjectTracker.Library.ProjectList>();

This allows the viewmodel or other presentation layer code to retrieve business objects like this:

var obj = await ProjectList.GetProjectListAsync();

No need for async callback handlers or the other messy goo from a typical WPF/Silverlight application. Of course WPF 4.5 will be able to use the await keyword too, so only SL/WP7 will still require the callback handler model when all is said and done.

Although these are early days, and I am still working through all the features of CSLA .NET to make sure they work on WinRT, it is nice to know that data binding, business/validation rules, and the data portal are all functional already. I expect to still do some work around authorization rules, and the local data portal implementation – but the vast majority of CSLA 4 functionality is already working just fine on WinRT and that makes me very happy!

Wednesday, March 21, 2012 8:49:28 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, March 14, 2012

One issue I’ve encountered while building Metro-style WinRT apps on Windows 8 is the need to have my app interact with a WCF service running on the same machine.

This is obviously a common scenario for any n-tier or SOA app development. The challenge we face is that WinRT apps are blocked from calling back to localhost ( The challenge and solution are described here:

To find the real application name (moniker) necessary, I wrote a simple command line utility to read the registry:

using System;
using Microsoft.Win32;

namespace WinRtAppList
  class Program
    static void Main(string[] args)
      var reg = Registry.
        OpenSubKey("Local Settings").

      var items = reg.GetSubKeyNames();
      string query = null;
      if (args.Length > 0)
        query = args[0].ToLower();

      foreach (var item in items)
        var app = reg.OpenSubKey(item);
        var displayName = app.GetValue("DisplayName").ToString();
        if (string.IsNullOrEmpty(query) || displayName.ToLower().Contains(query))
          Console.WriteLine("  SID:     " + item);
          Console.WriteLine("  Moniker: " + app.GetValue("Moniker"));


Nothing fancy, but it helps avoid the need to dig around in the registry with regedit just to find the application moniker.

Wednesday, March 14, 2012 7:57:34 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, March 13, 2012

I just read this article about what’s wrong with Windows 8:

The author makes some valid points. Most notably, in the consumer preview there are a ton of inconsistencies where the user is dumped into legacy mode (sorry, Desktop mode) when doing things as common as setting up a printer. That’s clearly confusing, and Microsoft has their work cut out to replace all the OS dialogs between now and release.

And the fact that there’s no obvious way out of Desktop mode once you get there is a problem. If you happen to accidentally get your mouse in the far lower-left corner of the screen you might escape, otherwise normal users just get trapped there with no way out. That’s pretty silly.

But toward the end of the article he makes an observation that I think is completely faulty:

“I don’t see touch being that important of a driver to either sell new PCs or a new operating system. Outside of Microsoft and a small number of power users, I don’t really see a demand for touch for PCs from either enterprise of consumer markets. Instead, what we have is Microsoft trying — once again — to stir up interest in touch devices.”

Apparently the author hasn’t noticed the massive uptake of iPad and Kindle Fire devices all over the place – at the consumer and corporate level. It is an understatement to say that demand exists for touch devices, and it would be absurd to think Microsoft would ignore that demand.

Or perhaps the author is suggesting that nobody wants a PC with touch. That they’d rather carry a PC for work, and a totally different type of device for touch? That is possible, but it seems unlikely that people would choose to spend twice the money and carry twice the hardware just to have two different experiences – at least if they have a choice of carrying one device that is good for work and play.

There are many reasons I’m motivated to see Windows 8 be successful (though I agree that success isn’t a foregone conclusion). Perhaps the biggest though, is apps. For touch, keyboard, and mouse, I want apps.


Because apps are the resurgence of the smart client and distributed computing. And there are no apps on the PC, so PC users are increasingly stuck using the second-class web interfaces to interact with the world.

Take almost anything – news, weather, stocks, social services like Facebook – you name it. PC users have to interact with these things via the web, reducing their super-powerful PC to a dumb terminal. But mobile device users get rich, smooth apps that are a lot more fun to use.

Given a choice, would you interact with Facebook via a web UI, or a nice app with clear navigation, nice animations, and well-considered user interaction? People have spoken – Facebook apps for tablets and phones are the primary way to interact with the social service over the web UI.

As a PC user I am increasingly left out. Left to suffer with browser-based experiences while my wife uses her iPad to interact with the same services in a more enjoyable manner.

It seems obvious now that apps will never come to the Win32/.NET PC world. So the only way to have decent interaction with the world at large is to figure out a way to get apps on the PC – and that is clearly via WinRT and Metro.

I think the lack of apps on the PC is because there’s no store, so no easy way to find and install such apps. Microsoft could have created an app store for Windows 7, but Win7 doesn’t offer a fully sandboxed runtime environment where such apps can be virus and harm-free to the end user.

I also think Microsoft could have created such a sandbox world based on Silverlight, without the need to create a whole new operating system. It would have been possible to enable Silverlight apps to be directly hosted on Win7, and to be purchased from a centralized and curated store.

But that wouldn’t have addressed the tablet and touch issues.

So what we’ve got is a new operating system, with a runtime designed from the ground up to support safe apps that are deployed from a store. And from a .NET developer perspective this new Windows Runtime (WinRT) is extremely close to Silverlight in terms of its development model. So in a sense Microsoft is doing exactly what you’d expect to enable apps – but they are also enabling tablets and touch.

In short, I am looking forward to Windows 8 because it breathes new life into the smart client and distributed computing world – and because as a user I can finally get a first-class experience for interacting with news, weather, and social services on the “web”.

Tuesday, March 13, 2012 9:56:44 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, March 7, 2012

I’ve spent a couple days using Windows 8 on my laptop now. And I’ve been using it on my tablet for a long time (Dev Preview and now Consumer Preview).

To get this out of the way right off: Windows 8 is clearly designed for tablets first, and desktop/laptop machines second. I really enjoy using it on the tablet, and it is fine on the laptop, but perhaps not as nice as Windows 7.


It is (or feels) faster than Win7 on the same machine. Win8 is just snappy. Microsoft likes the phrase “fast and fluid”, and it is fluid with touch, but it is snappy with keyboard/mouse.

Desktop usage

I’ve now pinned my common apps to the desktop start bar, just like I did with Win7. I had all my apps pinned in Win7 too, and rarely used the Start menu to launch anything, and the same is true in Win8.

I am finding that I rarely leave the desktop at all really. So in that regard, Win8 is just a slightly faster Win7. Most of what I’ve been doing has involved the use of Outlook, Word, Excel, IE, and Visual Studio – all of which run happily on the desktop, and so I often forget that I’m running Win8.

WinRT Metro style usage

When I do leave the desktop for WinRT, it has been to launch apps so I can pin them on the desktop start bar, or to play around with the various Metro style apps available. I’ve already discussed how pinning the apps on the desktop leads to a Win7-like experience, so I’ll now move on to my thoughts on using the Metro style apps with keyboard/mouse.

By way of disclaimer, I find the various Metro style apps to be incredibly inconsistent on both the tablet and laptop. They are clearly all works in progress. Some are better than others, but the lack of consistency in terms of the “back” concept and general navigation is really annoying. Microsoft has a lot of work to do just to get their own Metro style apps to be consistent and pleasant, and I don’t know how they will convince the creators of other apps to do a better job…

(as an aside, iPad users have told me that they are often frustrated with the lack of consistency across iPad apps too – so maybe this is just the future we’re embracing – one where every app makes up its own rules and us users have to just suck it up…)

“Back” concept frustration

My biggest issue with Metro style apps is the “back” concept. This comes in two forms: there are two “back” concepts, and apps don’t consistently implement the “back” concept they control.

First, a left-swipe is “back” to the previous app, and this is an OS concept. And apps can implement their own “back” concept, often with an arrow pointing left, or an X icon, or something else – and that moves you back within the context of the app.

Having these two back concepts isn’t so bad until one app launches another. The most common scenario is the People hub launching IE. So I was in the People hub, reading what people have been doing, now I’m in IE. I might click on a couple links in IE too. So now I can use the IE back button to move back through IE, but I (the human user) have to know to use a left-swipe to get back to the People hub. Personally I find this jarring and frustrating. Especially when compared to Windows Phone, where the back button would take me back through the web pages, and then back to the People hub. Smooth and consistent.

(I suspect it is too late in the game for Microsoft to address this issue – but I also suspect it will be the butt of jokes about Win8 UX design for the next decade or so, because it is a serious PITA)

To make this whole thing worse, the “back” concept implemented by each app is really under the app’s control. And every app seems to make up their own way to handle the scenario. Some examples:

  • The back button is always visible in the upper-left of the UI, wasting space, and not near my thumb (on the tablet) so I have to shift my hands to go back – yuck!
  • The back button is in the app bar, but in the top bar, not the bottom, forcing me to swipe or right-click in the app bar, then shift my hands to go back – super yuck!
  • The back button is in the upper-right corner (either ways visible or in the app bar) – which is amazingly terrible!
  • The back button is in the app bar in the lower-left, forcing me to swipe or right-click in the app bar, but at least I don’t have to shift my hands – this is so so…

On a laptop, I’m constantly moving my mouse this way and that to find and click the back/close buttons where ever a particular app decided to put the button.

Personally, I think Microsoft should have put a Back button on the actual device like they did on the phone. Or the left-swipe should be back for the app, and then the OS, more like the WP7 back button… Again, I suspect we’re just in for a lot of pain and jokes for years to come Sad smile

Mouse support

The start screen and most Metro style apps provide some basic support for the mouse. Nothing spectacular, but there are scrollbars for panning and scrolling and they work fine. Right-click is like swiping in the app bar with touch.

Some things are still easier with the mouse, like selecting something and interacting with it. Much more precise and reliable with the mouse than with touch.

On the whole, the mouse support in Metro style apps is adequate, but not particularly good. That’s true for the start screen and all the other apps I tried.

Update: After installing the touchpad driver and enabling the various scroll/pan/zoom/rotate gestures supported by the touchpad, I am finding the “mouse” experience to be much more satisfying in Metro style apps. I’m not sure if this really counts, because these aren’t technically “mouse” gestures. But for a laptop user with a decent touchpad (like on my Dell), this does make a big difference.

Keyboard “support”

The start screen has a bunch of Windows key shortcuts for the keyboard. Learn these and the start screen becomes quite pleasant (imo) for a keyboard/mouse user. The start screen’s mouse support is limited, but with the keyboard shortcuts it is easy to be fast and productive from the start screen.

Individual apps do or don’t work with the keyboard much or at all. Few of the apps seem to take the keyboard into account much at all, and others use the keyboard, but not in a way I find intuitive.

For example, the US News app (which is visually stunning) uses left and right arrow keys to move between news stories. But there doesn’t seem to be any way to use the keyboard to pan the current story left or right. Because all stories must be panned left to read the text, the result is that you must use the mouse and scrollbar to read the story. That’s just lame.

I’d have expected left/right arrows to pan the story, and perhaps page-up/down to move between stories.

Other apps do use left/right arrow to pan the current item, but usually at such a slow rate of panning as to be useless.

I know, these apps were rushed out so they could be in the store for the Consumer Preview launch. And I’m sure the primary focus was on touch, not keyboard/mouse support.

On the other hand, I’m hoping that by recording my thoughts and experiences as a laptop user, future versions of these apps, and other future apps, will remember that desktop/laptop users will run Win8 too, and that these apps need to support non-touch devices as well as touch.

Metro style summary

Microsoft has made it clear that their intent is for Metro style apps to treat touch as a first-class interaction model. Other than the apps having the consistency of the web in 1997 (which is to say none), I would say that they’ve achieved that goal. These apps are all about touch.

But Microsoft also made it clear that their intent is for keyboard/mouse to be a first-class interaction model. The start screen certainly treats the keyboard as first-class. The mouse is probably second-class at this point. Individual Metro style apps are pretty much completely treating keyboard/mouse as an afterthought – let’s go with third-class.

So this is a call to Microsoft to stick with their intent and to keep pushing the keyboard/mouse and touch models in parallel and with parity.

And even more, this is a reminder to all of us app developers that it is our responsibility to ensure that keyboard/mouse and touch users are all happy with our user experience designs.

Finally, it is a call to Microsoft to do something about the horrible “back” concept issue. Again, I recognize it is probably too late to fix the dual model issue. But at least provide some STRONG guidance (and a consistent example in your own apps) on how to implement the application back concept. For lack of anything better, my vote is for an always-visible button in the lower-left of the screen. Don’t make me bring up the app bar, and really don’t make me shift my hands to reach the top (left or right) of the screen.


To close, I am finding Win8 to be a perfectly good beta experience. Is it ready for prime time? Of course not, it is a beta. If you install it on a machine can you be productive and happy? Absolutely yes.

This is especially true if you (like me) are already used to pinning your common apps to the desktop start bar. Do that, and you’ll hardly know you are running Win8 at all.

The immature state of the Metro style apps doesn’t really worry me. As more and more people use these apps and provide feedback like I’m doing here, the user experiences provided by those (and future) apps will improve for touch and keyboard/mouse users alike.

I’m quite excited about Win8 and WinRT and the future of the platform. It really does bring user experience into the forefront of application development. The difference between apps that have attention to UX and those that don’t is the difference between a usable app and one that sucks productivity and joy from life.

It is now up to all of us as developers to recognize this reality, and to provide a UX that does bring joy and productivity to our users – keyboard, mouse, or touch.

Wednesday, March 7, 2012 4:48:41 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

At a time when many organizations are moving from Windows XP or 2000 to Windows 7, the last thing a lot of people want to think about is Windows 8. At the same time, it is incredibly clear that the future of client computing is undergoing a major shift thanks to the rapid growth of iPad and other tablet devices. Windows 8 is not only the next desktop operating system from Microsoft, but it is also Microsoft’s answer to this substantial shift toward low-power touch-based client devices.

This change impacts not only the operating system, but the underlying application development model. The new Windows Runtime (WinRT) development platform represents an evolution for .NET developers, and a significant shift for non-.NET developers.

Realistically, enterprises should expect two things. First, the enterprise desktop/laptop platform will most likely continue its shift to Windows 7, and may remain on Windows 7 for many years. Second, the enterprise is already forced to deal with iPad and other tablet devices, and they’ll need to deal with (or embrace) Windows 8 tablets in the same way.

To the first point, I think it unlikely that most organizations will roll out Windows 8 on a broad scale to desktops or laptops. Most organizations are just now moving from XP/2000 to Windows 7, only because those ancient operating systems will soon be entirely unsupported. It is not realistic to think that organizations will immediately move from Windows 7 to Windows 8. It is more realistic to think that they’ll be on Windows 7 for 5-10 years, and will then move to “Windows 11” or something along that line.

As a result, organizations will be building and maintaining applications using Microsoft .NET (WPF, Silverlight, Windows Forms) for many years to come. There is no WinRT for Windows 7, so that new development platform will be off limits for mainstream enterprise application development targeting the desktop/laptop space in the foreseeable future.

To the second point, the reality that end users in organizations will acquire and use tablets on their own, if not supplied by the organization, is already happening. The flood gates are open, and organizations are now left to deal with the results. A chaotic landscape composed of iPads, random incompatible Android devices, and soon Windows 8 devices.

This is where things get interesting. Windows 8 on Intel devices can run the same .NET applications as a desktop or laptop. They can also run WinRT applications, which (when built using .NET) are extremely similar to Silverlight applications. Windows 8 on ARM devices will only run WinRT applications.

iPad and Android devices require completely different application development using tools unlike .NET. No code or functionality sharing between existing .NET desktop/laptop applications and these platforms is possible. Truly embracing these platforms means building up duplicate development staff for Objective C and Java, or switching entirely away from traditional smart client development to a pure HTML5 model. Sadly, HTML5 isn’t compatible across all these devices either, so even that isn’t an obvious solution.

In reality, it might be less expensive for organizations to buy employees Windows 8 tablets than to pay developers to re-implement applications across multiple platforms, and to then support those multiple implementations over time. In fact, I suspect it will almost always be cheaper to spring for a few Windows 8 tablets than to pay for duplicate software development and maintenance forever.

To achieve the broadest reach, Windows 8 apps should target WinRT. That allows the apps to run on Intel and ARM devices. As I mentioned earlier, when using .NET to build WinRT applications, the development model is very similar to Silverlight. This means that existing WPF and Silverlight developers will have a relatively easy time shifting to WinRT, and substantial amounts of Silverlight application code will often just work on WinRT.

Frameworks such as CSLA .NET provide even more cross-platform compatibility. For example, the business logic code for applications written using CSLA 4 that target Silverlight will just recompile for WinRT, usually with no changes required at all. The vast majority of business logic from WPF or Windows Forms applications written using CSLA 4 will also just recompile for WinRT.

In summary, Windows 8 represents a major factor in enterprise application development strategy. In the short term, it might offer a lower-cost way to get users onto tablets without the high cost of duplicate software development, or dealing with the cross-platform HTML5 issues. In the long term, WinRT appears to be Microsoft’s new strategic development platform, so organizations need to be considering how to move to this platform over a period of years.

Wednesday, March 7, 2012 1:36:50 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, March 5, 2012

I’ve now installed the Windows 8 Consumer Preview four times on three machines.

First, I did a reimage of the tablet I got at //build/ last fall. That was a smooth and seamless process, and I’m really enjoying using Windows 8 on the tablet.

Second, I did an install into a VirtualBox virtual machine on my main desktop. This is not satisfying. The CP release is slower in VirtualBox than the Dev Preview was, and so I’ve already deleted the virtual machine. Clearly we’re at a point where a VM just isn’t going to cut it unless you are desperate. (the alternative is boot from vhd, and people seem to be having good luck with that)

In short, I don’t think I’ll mess with trying to run Win8 in a VM anymore.

Third, I did an upgrade of my Win7 laptop to Win8. This seemed to go very smoothly, but ultimately was a failure. Issues I encountered include:

  • I couldn’t link my Magenic domain user to a Microsoft user, so some apps (like SkyDrive) just didn’t work at all, and others kept prompting me for credentials
  • I couldn’t get a dev license from VS11 to debug Metro style apps in WinRT
  • The login process took forever and a day – every time; I’m not sure what it was doing, but it was really slow
  • Other hard-to-define quirky issues that I didn’t see on the tablet – minor stuff that would be annoying long-term

The inability to get a developer license key for Metro style apps was obviously a show-stopper. I know other people who’ve gotten a key on machines joined to a domain, so I doubt that was the issue. My current working theory is that something gets messed up (or got messed up in my case) when upgrading from Win7.

In short, I don’t think I’ll be upgrading from Win7 to Win8 again.

Fourth, I did a fresh Win8 install on my laptop. This also went smoothly, though I have some concerns about it automatically getting all the right drivers (like for the motherboard chipset and power control). I guess we’ll see what happens there.

On the whole, running Win8 on a laptop is an adequate experience. The new start screen isn’t as friendly to a mouse as to touch, but it works.

On my tablet and laptop I’ve installed Office 2010 and Lync. These applications appear to work just fine, though they are obviously ill-suited for touch-based usage.

I’ve also installed Visual Studio 11 three times now.

First, I installed it on the tablet. That was a fresh Win8 image, and VS11 installed and ran without a hitch.

Second, I installed it on the upgraded laptop. That was a side-by-side install with an existing VS10 installation. The VS11 install went without a hitch, but as I mentioned earlier, I was unable to get a developer license key for Metro style apps, so it was pretty useless.

Third, I installed it on the reimaged laptop – but after installing VS10 SP1 again. So again, a side-by-side install. The VS11 install went without a hitch, and I’m now happily working on Metro style apps targeting WinRT.

Monday, March 5, 2012 8:20:26 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, November 30, 2011

I have been working with some of my colleagues at Magenic to write a whitepaper that summarizes our view on how “Windows 8” and WinRT affect existing Microsoft developers.

If you’ve read my previous WinRT related blog posts you’ll see that the whitepaper is similar, but provides more formal analysis and information in a presentable format.

Wednesday, November 30, 2011 10:33:35 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Saturday, November 12, 2011

One of the primary goals for CSLA 4 version 4.3 (the next version we’ll be creating) is to improve the performance of the MobileFormattter that is used for Silverlight and Windows Phone applications. This is made all the more important, because it will also be used in WinRT applications in the future.

Sergey (a CSLA dev team member, and Magenic colleague) has been doing some heavy research into this area, and we’d originally thought to do the changes as part of the 4.2 release. It turns out that doing a really great job of optimization will require some breaking changes – at least for people who aren’t using managed backing fields. So we are deferring the bigger changes until 4.3.

In the meantime, Sergey has blogged about how to improve performance of MobileFormatter in 3.8 and 4 (4.0, 4.1, or 4.2). These are changes you can make to your CSLA codebase now if you want some of the performance benefits without waiting for the “big change” that’ll come in 4.3.

Saturday, November 12, 2011 12:41:27 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, November 9, 2011

Joe writes a nice summary of why a web app is not a web page – it is something different, and in important ways.

This distinction becomes very important when considering building H5/js apps on WinRT in Windows 8, or if you believe (in general) that H5/js will replace existing dev platforms like Java and .NET. For that to happen, we have to stop thinking about HTML and js as web technologies – they must be thought of as general purpose technologies that sometimes happen to be used on the web too.

Web | WinRT
Wednesday, November 9, 2011 10:10:01 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, November 8, 2011

Disclaimer: I know nothing. The following is (hopefully) well educated speculation on my part. Time will tell whether I’m right.

I really like Silverlight. I’ve been a strong proponent of Silverlight since 2007 when I rushed to port CSLA .NET to the new platform.

In fact, Magenic provided me with a dev and test team to make that transition happen, because we all saw the amazing potential of Silverlight.

And it has been a good few years.

But let’s face reality. Microsoft has invested who-knows-how-much money to build WinRT, and no matter how you look at it, WinRT is the replacement for Win32. That means all the stuff that runs on Win32 is “dead”. This includes Silverlight, Windows Forms, WPF, console apps – everything.

(this is partially in answer to Mary-Jo’s article on Silverlight 5)

I wouldn’t be surprised if Silverlight 5 was the last version. I also wouldn’t be surprised if .NET 4.5 was the last version for the Win32 client, and that future versions of .NET were released for servers and Azure only.

Before you panic though, remember that VB6 has been “dead” for well over a decade. It died at the PDC in 1999, along with COM. But you still use VB6 and/or COM? Or at least you know organizations who do? How can that be when it is dead??

That’s my point. “dead” isn’t really dead.

Just how long do you think people (like me and you) will continue to run Win32-based operating systems and applications? At least 10 years, and many will probably run 15-20 years into the future. This is the rate of change that exists in the corporate world. At least that’s been my observation for the past couple decades.

Microsoft supports their technologies for 10 years after a final release. So even if SL5 is the end (and they haven’t said it is), that gives us 10 years of supported Silverlight usage. The same for the other various .NET and Win32 technologies.

That’s plenty of time for Microsoft to get WinRT mature, and to allow us to migrate to that platform over a period of years.

I don’t expect WinRT 1.0 (the Windows 8 version) to be capable of replacing Win32 or .NET. I rather expect it to be pretty crippled in many respects. Much like VB 1.0 (and 2.0), .NET 1.0 and 1.1, Silverlight 1 and 2, etc.

But Windows 9 or Windows 10 (WinRT 2.0 or 3.0) should be quite capable of replacing Win32 and .NET and Silverlight.

If we assume Win8 comes out in 2012, and that Microsoft does a forced march release of 9 and 10 every two years, that means 2016 will give us WinRT 3.0. And if we hold to the basic truism that Microsoft always gets it right on their third release, that’ll be the one to target.

I think it is also reasonable to expect that Win9 and Win10 will probably continue to have the “blue side” (see my Windows 8 dev platform post), meaning Win32, .NET, and Silverlight will continue to be released and therefore supported over that time. They may not change over that time, but they’ll be there, and they’ll be supported – or so goes my theory.

This means that in 2016 the clock might really start for migration from Win32/.NET/Silverlight to WinRT.

Yes, I expect that a lot of us will build things for WinRT sooner than 2016. I certainly hope so, because it looks like a lot of fun!

But from a corporate perspective, where things move so slowly, this is probably good news. Certain apps can be ported sooner, but big and important apps can move slowly over time.

What to do in the meantime? Between now and 2016?

Focus on XAML, and on n-tier or SOA async server access as architectural models.

Or focus on HTML 5 (soon to be HTML 6 fwiw, and possibly HTML 7 by 2016 for all we know).

I’m focusing on XAML, creating a CSLA 4 version 4.5 release that supports .NET 4.5 on servers, Azure, Windows (Win32), and Windows (WinRT). And Silverlight 5 of course.

In fact, the plan is for a version 4.3 release to support Silverlight 5, then version 4.5 with support for .NET 4.5 and WinRT.

I suspect that you can use Silverlight or WPF as a bridge to WinRT. The real key is architecture.

  1. An n-tier architecture is fine, as long as the data access layer is running on a server, and the client uses async calls to interact with the server. WinRT requires a lot of async, at a minimum all server interactions. Silverlight forces you to adopt this architecture already, so it is a natural fit. WPF doesn’t force the issue, but you can choose to do “the right thing”.
  2. You can also build your client applications to be “edge applications” – on the edge of a service-oriented system. This is a less mature technology area, and it is more costly. But it is also a fine architecture for environments composed of many disparate applications that need to interact as a loosely coupled system. Again, all service interactions by the edge applications (the ones running on the clients) must be async.
  3. Or you can build “hybrid solutions”, where individual applications are built using n-tier architectures (with async server calls). And where some of those applications also expose service interfaces so they can participate as part of a broader service-oriented system.

I favor option 3. I don’t like to accept the cost and performance ramifications of SOA when building an application, so I’d prefer to use a faster and cheaper n-tier architecture. At the same time, many applications do need to interact with each other, and the requirement to create “application mashups” through edge applications happens from time to time. So building my n-tier applications to have dual interfaces (XAML and JSON for example) is a perfect compromise.

The direct users of my application get n-tier performance and maintainability. And the broader organization can access my slower-moving, standards-based, contractual service interface. It is the best of both worlds.

So do I care if Silverlight 5 is the last version of Silverlight?

Only if WPF continues to evolve prior to us all moving to WinRT. If WPF continues to evolve, I would expect Silverlight to, at a minimum, keep up. Otherwise Microsoft has led a lot of people down a dead-end path, and that’s a serious betrayal of trust.

But if my suspicions are correct, we won’t see anything but bug fixes for WPF or Silverlight for many years. I rather expect that these two technologies just became the next Windows Forms. You’ll notice that WinForms hasn’t had anything but bug fixes for 6 years right? The precedent is there for a UI technology to be “supported, stable, and stagnant” for a very long time, and this is my expectation for WPF/SL.

And if that’s the case, then I don’t care at all about a Silverlight 6 release. We can use WPF/SL in their current form, right up to the point that WinRT is stable and capable enough to act as a replacement for today’s Win32/.NET applications.

Tuesday, November 8, 2011 8:51:12 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, October 25, 2011

Based on comments from my previous Windows 8 Development Platform blog post (thank you to Shawn and Slavo in particular), here’s an updated Magenic diagram.


This one adds the Chakra js engine to the WinRT and desktop sides of the diagram, and it expands the detail of WinRT and Win32 to include things like COM, GDI+, and DirectX.

The result is that DirectX and GDI+ are duplicated – they are shown as a presentation technology at the top (which is valid), and as a core part of the OS APIs too (which is also valid). I’m not entirely sure that this adds clarity (or causes confusion?), but it seems like a reasonable addition to me based on Shawn’s comments.

The DirectX/GDI+ addition is directly valuable (I think), because it clearly illustrates that GDI+ is a Win32 thing, and doesn’t exist in the WinRT world.

Tuesday, October 25, 2011 10:28:14 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, October 24, 2011

I’ve posted a number of blog entries on Windows 8 and WinRT, and thought it might be worth summarizing them. I suggest reading them in this order:

Win8, Metro, and WinRT terminology – why WinRT != Metro, and when I think each term should be used

Windows 8 Development Platform Clarified – addresses questions about today’s technologies and how they map into Windows 8, includes the Magenic Windows 8 platform diagrams

Updated Windows 8 Dev Platform - revised/improved Windows 8 Development Platform graphic

WinRT and business apps – why I am convinced that WinRT is relevant for business developers (and future business app development)

Silverlight 6 doesn't matter - why the Microsoft product support strategy, and WinRT, mean that Silverlight 6 (whether it exists or not) doesn't matter

Migrating smart clients to WinRT – somewhat CSLA .NET specific discussion on what you can do today to ease migration to WinRT in the future

WinRT and .NET – first thoughts based on the //Build/ conference – a bit rambling, but still generally useful

Why MVVM – technical post discussing why using MVVM in WPF/SL today will help migrate to WinRT in the future

CSLA on WinRT (project start) – initial findings as I started porting CSLA .NET to WinRT

WinRT BackgroundWorker type – technical post showing one way to recreate BackgroundWorker using async/await in WinRT

Monday, October 24, 2011 12:04:36 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

At Visual Studio Live! last week I used some slides that several of us at Magenic have been working on to provide clarity around the “Windows 8” development platform, based on what we know from //Build/ 2011. I wanted to share some of these slides here.

We’re also working on a related white paper that will be online soon, and I’ll link to that when it is available.

First, is the obligatory Microsoft “boxology” diagram that generated so much controversy due to its over-simplistic design:


Although this diagram is usually found to be lacking, it did set the standard for the green/blue color scheme and overall layout of everyone else’s “boxology” diagrams – including ours.

Magenic Windows 8 Diagram

Here is the Magenic diagram that provides more detail and clarity:


Win32 (blue) is the existing Windows operating system API, and it shouldn’t be surprising that it supports existing technologies.

WinRT (green) is the new Windows operating system API, that I suspect will replace Win32 over a period of many, many years. In my mind this is absolutely necessary. Win32 is more than 16 years old, and just doesn’t provide the capabilities we want in a modern operating system. Hopefully the new WinRT API will provide these capabilities, and will last for another 15+ years.

The idea in the Magenic diagram is to clearly show the WinRT (Metro, green) and Win32 (desktop, blue) sides of the Windows 8 platform, and the various development technology stacks that can be used to build software for each operating system API.

To provide even more clarity, we have a series of highlight diagrams for various technology stacks.

The Desktop (blue)

I’ll start by walking through all the technology stacks on the desktop (blue) side of the master diagram:

  • Silverlight
  • WPF
  • Web sites with plugins
  • Web sites with pure HTML/js
  • Windows Forms
  • C++, MFC, ATL

Each technology maps directly from today into Windows 8.



Silverlight runs in Win8 in the desktop browser, and out of browser, just like it does today on Win7.



WPF runs in the Win8 desktop just like it does today in Win7.

Web sites with plugin support


Today’s web sites that use HTML, js, Flash, Silverlight, ActiveX, and other common web technologies all run in the desktop web browser. This is the same as web sites work today in Win7.

Web sites with pure HTML/js


If a web site only uses HTML, CSS, and js, then it can run in the WinRT and desktop browsers interchangeably. Microsoft clearly expects this type of web site to become more common over time, though it is interesting that a large number of existing Microsoft web sites are really only useful in the desktop browser.

Windows Forms


Windows Forms continues to run in Windows 8 on the desktop, just like it does in Win7. This isn’t surprising, given that Windows Forms is almost certainly still the dominant technology for building Windows smart client applications, even though the technology hasn’t had anything beyond bug fixes since 2005. It goes to show how stability in a platform is important, and attracts widespread use for business development.



Although little business development is done with C++ anymore, this technology remains relevant for game developers, OS and device driver developers, and every now and then I encounter someone using it for business development. From my perspective, the important thing about C++ support is that my favorite games will probably continue to run on Win8 in the desktop.

WinRT (green)

Next, I’ll walk through the three technologies that support the WinRT API:

  • WinRT .NET
  • WinRT HTML 5
  • WinRT C++

Each technology draws from existing technologies by the same names, but in each case there’s a little “twist” as you move from the Win32 to the WinRT platform.



I expect this to be the most widely used technology stack for building WinRT applications. The .NET available to WinRT applications is (I think) best thought of as being like .NET on the Windows Phone. It is basically the Silverlight subset of .NET, plus a bunch of WinRT-specific features and capabilities. The differences between Silverlight and WinRT are a bit more dramatic than with WP7, but the analogy remains quite accurate.

The XAML is very close to Silverlight and WPF, and the types of code you can write using C# and VB are very comparable to what you can write today using Silverlight.

As a preview: the white paper we’re creating at Magenic ultimately concludes that using Silverlight today provides the easiest transition to WinRT in the future. Not seamless or trivial, but practical. We also conclude that WPF can enable a WinRT transition too – especially if you limit your use of WPF and .NET to the Silverlight subset of behaviors and features.



Microsoft has made much of the HTML 5 technology stack for building WinRT applications. In no way are we talking about web sites, web pages, or web applications here. This is smart client development done using technologies that were previously web-focused.

For a .NET developer, the technologies map like this:

  • HTML instead of XAML
  • JavaScript instead of C#
  • WinJS instead of the .NET BCL

In my conversations with traditional web developers, it is a brain-bending moment when I point out that there is no web server involved, and so no server-side code at all here. All the stuff that is done in ASP.NET or PHP is now done in JavaScript. From an architecture, design, and application functionality perspective, a WinRT HTML 5 app is almost, but not completely, unlike a web app.

On the positive side, if a web developer can learn and embrace the smart client architectural model, their skills with HTML, CSS, and JavaScript will carry over to this new platform. Some HTML and CSS assets, and perhaps some js assets, will carry from web development into this type of smart client development as well.

WinRT C++


Finally, C++ remains relevant on WinRT as well. This should come as no surprise, given that the Windows OS developers primarily use C++, and there’ll hopefully be games and other applications that are traditionally created using this technology.

I also suspect that Objective C apps will port to WinRT more directly through C++ than with C# or js, and (at least for my part) I hope that some of the existing iPad/iPhone apps quickly make their way onto WinRT so I can enjoy them.


Through this series of diagrams, we clearly show how today’s technologies map directly into the Win8 desktop world, still running on the Win32 API. And we show the three technology stacks that enable development of applications on the new WinRT API.

From everything we know today, it seems clear that migrating to WinRT will require effort, regardless of the technology used today, or in the Win8 desktop. Of all existing technologies, Silverlight and then WPF appear to offer the easiest migration. HTML 5, css, and js skills, along with some code assets will also migrate, but there’s a non-trivial architectural difference between web development and smart client development that shouldn’t be overlooked.

As Microsoft releases updates to the Win8 preview and moves into a beta process, I’m sure that we’ll learn more about the platform and how existing technologies map into the future. It will be interesting to see how we need to update these diagrams as Microsoft provides more information over time.

Windows 8 is exciting, and the new WinRT platform is long-overdue. I look forward to building WinRT applications in the not-to-distant future!

Monday, October 24, 2011 11:08:54 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, October 18, 2011

Magenic sent a team to Microsoft’s recent //build/ conference to learn about the new Windows 8 and WinRT platform. You can now watch a series of interviews with several of Magenic’s thought leaders to get an insight into the first impressions about Windows 8:

Tuesday, October 18, 2011 3:34:17 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, October 14, 2011

With all the new terminology and conceptual surface area that comes with the OS code-named “Windows 8”, I’ve been struggling to come up with clarity as I discuss the technology. In the absence of true clarity from Microsoft, we’re left to interpret that they’ve said and come up with our own consistent terminology.

Here’s my current thinking:

  • Windows 8 – the new operating system that runs in a “dual mode”: Desktop (Win32) and WinRT
  • Win32 – the OS API that supports today’s applications in Win8
  • WinRT – the new OS API that supports future applications
  • Metro – a user experience design language often used when building WinRT applications

If I’m right, this is important, because people will ultimately be building business applications on WinRT. Those apps may or may not be strictly “Metro”, but by running on WinRT they’ll gain the benefits of the new runtime API, services, and application model.

People talk about “Metro apps”, but even in the Microsoft samples there are apps running on WinRT that violate those standards left and right. So it is extremely clear that WinRT apps might or might not be “Metro”.

Additionally, it seems pretty reasonable to think about building Silverlight or WPF apps, even today, following the Metro standards. Some of that might require a lot of work (at least until third party control vendors create some new components for us), but it is surely possible.

So you could argue that "Metro apps” might transcend WinRT. In fact, Metro is also used to describe Windows Phone apps, and they are mostly written in Silverlight.

So I think there are “WinRT apps”, and this includes any/all apps written on the WinRT API.

Then there are “Metro apps” that are probably a WinRT app, that also follows the Metro user experience guidelines.

This terminology helps a lot when talking about .NET, present and future.

Right now, today, we have some flavors of .NET:

  • .NET Full profile
  • .NET Client profile
  • Silverlight
  • Windows Phone

It seems to me that Windows 8 just adds a new option:

  • .NET WinRT profile

As I think about the future of CSLA .NET, for example, this is how I approach the issue. We’ve already put in a lot of work to make the framework support the existing flavors of .NET (plus mono, mono for iOS, and mono for Android). Much of that effort lays the necessary groundwork for also supporting this new WinRT flavor of .NET.

Friday, October 14, 2011 9:04:37 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, October 12, 2011

There is no BackgroundWorker (BW) component in WinRT. Although that is arguably a good thing, I have CSLA .NET code that relies on this component. I can’t eliminate the BW from CSLA, because I need to continue to support .NET, Silverlight, and Windows Phone, even as I add support for WinRT.

Because .NET/SL/WP7 don’t (yet) have the async/await keywords, and WinRT doesn’t have BW, I need to come up with a solution that leaves existing code/behavior alone, and yet provides comparable behavior in WinRT.

To resolve this issue, I’ve created a BackgroundWorker type for WinRT. This type hasn’t gone through extensive testing, but it is a good start at least:

// <copyright file="BackgroundWorker.cs" company="Marimer LLC">
//     Copyright (c) Marimer LLC. All rights reserved.
//     Website:
// </copyright>
// <summary>Implementation of old BCL BackgroundWorker ported to WinRT.</summary>
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Windows.UI.Core;
using Windows.UI.Xaml;

namespace System.ComponentModel
  public class BackgroundWorker : DependencyObject
    private CoreDispatcher _dispatcher;

    public BackgroundWorker()
      _dispatcher = this.Dispatcher;

    public void CancelAsync()
      if (!WorkerSupportsCancellation)
        throw new NotSupportedException();
      CancellationPending = true;

    public bool CancellationPending { get; private set; }

    public event ProgressChangedEventHandler ProgressChanged;

    public void ReportProgress(int percentProgress)
      ReportProgress(percentProgress, null);

    public void ReportProgress(int percentProgress, object userState)
      if (ProgressChanged != null)
          (sender, args) =>
            ProgressChanged(this, new ProgressChangedEventArgs(percentProgress, userState));
          this, null);

    public bool WorkerReportsProgress { get; set; }
    public bool WorkerSupportsCancellation { get; set; }
    public bool IsBusy { get; set; }

    public event DoWorkEventHandler DoWork;
    public event RunWorkerCompletedEventHandler RunWorkerCompleted;
    protected virtual void OnRunWorkerCompleted(RunWorkerCompletedEventArgs e)
      if (RunWorkerCompleted != null)
        RunWorkerCompleted(this, e);

    public void RunWorkerAsync()

    public async void RunWorkerAsync(object userState)
      if (DoWork != null)
        CancellationPending = false;
        IsBusy = true;
          var args = new DoWorkEventArgs { Argument = userState };
          await Task.Run(() =>
            DoWork(this, args);
          IsBusy = false;
          OnRunWorkerCompleted(new RunWorkerCompletedEventArgs { Result = args.Result });
        catch (Exception ex)
          IsBusy = false;
          OnRunWorkerCompleted(new RunWorkerCompletedEventArgs { Error = ex });

  public delegate void DoWorkEventHandler(object sender, DoWorkEventArgs e);

  public class DoWorkEventArgs : EventArgs
    public DoWorkEventArgs()
    { }

    public DoWorkEventArgs(object argument)
      Argument = argument;

    public object Argument { get; set; }
    public bool Cancel { get; set; }
    public object Result { get; set; }

  public delegate void RunWorkerCompletedEventHandler(object sender, RunWorkerCompletedEventArgs e);

  public class RunWorkerCompletedEventArgs : EventArgs
    public RunWorkerCompletedEventArgs()
    { }

    public RunWorkerCompletedEventArgs(object result, Exception error, bool cancelled)
      Result = result;
      Error = error;
      Cancelled = cancelled;

    public Exception Error { get; set; }
    public object Result { get; set; }
    public bool Cancelled { get; set; }
Wednesday, October 12, 2011 12:32:14 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, October 3, 2011

People often ask “Why should I use MVVM? It seems like it complicates things.”

The most common reason hard-core developers put forward for MVVM is that “it enables unit testing of presentation code”.

Although that can be true, I don’t think that’s the primary reason people should invest in MVVM.

I think the primary reason is that it protects your presentation code against some level of change to the XAML. It makes your code more maintainable, and will help it last longer.

For example, build a WPF app with code-behind. Now try to move it to Silverlight without changing any code (only XAML). Pretty hard huh?

Or, build a Silverlight app with code-behind. Now have a user experience designer rework your XAML to look beautiful. Your app won’t build anymore? They changed numerous XAML types and there are now compiler errors? Oops…

Looking forward, try taking any WPF or Silverlight app that has code-behind and moving it to WinRT (Windows 8) without changing any code (only XAML – and the XAML will need to change). Turns out to be nearly impossible doesn’t it?

And yet, I have lots of CSLA .NET application code that uses MVVM to keep the presentation code cleanly separated from the XAML. Examples where the exact same code runs behind WPF and Silverlight XAML. I’m not quite yet to the point of having CSLA working on WinRT, but I fully expect the exact same code to run on Windows 8, just with a third set of XAML.

To me, that is the power and value of MVVM. Your goal should be no code-behind, viewmodel code that doesn’t rely on specific XAML types, and an abstract set of viewmodel methods that can be bound to arbitrary UI events.

Yes, MVVM is an investment. But it will almost certainly pay for itself over time, as you maintain your app, and move it from one flavor of XAML to another.

Does MVVM mean you can completely avoid changing code when the XAML changes? No. But it is a whole lot closer than any other technique I’ve seen in my 24+ year career.

Monday, October 3, 2011 9:59:08 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, September 28, 2011

I have been giving quite a lot of thought to the WinRT migration path. What is the outlook for taking a Windows Forms, WPF, or Silverlight app into WinRT/Metro in Windows 8?

The amount of effort required for any given application may vary radically, depending on the architecture used when building the application, and how well that architecture was implemented in the actual code. And it is obviously important to understand how much client-side application code uses .NET features that aren’t in WinRT, or that are substantially different in WinRT.

And of course I tend to look at this from a CSLA .NET perspective Smile  If you use CSLA 4 today, and you adhere to the architecture and coding structures recommended when using CSLA, most or all of your business layer code will probably move to WinRT without change.

So, rather simplified, and CSLA-centric, here’s a set of process flows:


Although the first decision point is “Using CSLA?”, you could replace that with “using a architecture/framework that abstracts all business, validation, authorization, data access and other application logic away from the UI, exposing a model that supports data binding and async server interactions”. Although I’m obviously biased, there are absolutely other architectures that offer the same layered abstraction to keep all business and data logic out of the presentation layer. And that’s really what’s required.

In the final analysis, if you have any business or data logic in your code-behind, or you aren’t using data binding to connect your existing UI views to some sort of business objects, you have some work ahead of you to get to that point.

Essentially all non-CSLA Windows Forms apps I’ve ever seen will require a complete rewrite. Most use DataSet objects, and therefore require total rework. And most use a lot of code-behind, and therefore require total rework. And a lot of them use numerous windows and modal dialogs, so the user workflow will require a complete rethink.

A surprising number of WPF apps are written much like Windows Forms apps, with code-behind, etc. Those apps will require much the same effort to migrate as Windows Forms. But if you’ve written your WPF app using MVVM, even without something like CSLA, and have strictly avoided code-behind, the migration probably won’t be too bad.

The big thing is that a lot of WPF apps aren’t written to assume async server interactions, and updating code to handle that can be a lot of work. WPF apps written using CSLA may already be using the async features in CSLA, and so can avoid this issue entirely. Worst case, if you are already using CSLA synchronously, the changes to move to async aren’t overwhelming.

If you have a Silverlight app, you are in the best position of anyone, because you are already using async server interaction, and can’t have made the mistake of using the DataSet. And if you are using MVVM without any code-behind your migration will probably be quite smooth.

If you are also using CSLA, then your existing business layer will probably translate to WinRT without change.

As I mentioned in a previous WinRT post, Windows 8 is years away for most organizations. At the same time, I do think that WinRT/Metro will be used for business app development.

Quite a number of people are mistakenly saying that “Silverlight is dead”, when in reality Silverlight has never been more important.

What are you going to use to build business apps in the years between now and when Win8 is available in your organization?

You might consider using the technology that appears to offer the easiest migration to WinRT… And that is Silverlight (plus MVVM and CSLA 4 Smile ).

Wednesday, September 28, 2011 11:35:58 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Sunday, September 18, 2011

A number of people have asked about the future of CSLA .NET on WinRT (and Windows 8 and Metro).

(fwiw, you can always check out the CSLA roadmap to see what I’m planning)

The short answer is that (when Win8 comes out) I expect to have a CSLA 4 version 4.5 release that supports .NET 4.5, along with WinRT.

These are two different things.

.NET 4.5 builds apps that run on the Win8 desktop, not in Metro. I imagine .NET 4.5 will also support Win7, but I don’t know for sure. I was able to build the existing CSLA 4 version 4.2 code in .NET 4.5 without change. But I do expect that some changes will be required to take advantage of .NET 4.5 features.

For example, ASP.NET Web Forms is getting a major facelift in 4.5, as is ASP.NET MVC. It is reasonable to expect that CSLA will need to accommodate those changes – though the bulk of the impact should be in the Csla.Web and Csla.Web.Mvc projects.

Whether there are any interesting changes to WPF or Windows Forms is, at this point, something I haven’t explored.

WinRT is closer to Silverlight than full .NET, but it isn’t Silverlight either. I spent a couple hours this evening starting the port of CSLA 4 version 4.2 to WinRT.

  1. I started with the Csla.Silverlight project, because it is closest to what will work in WinRT
  2. I added the DataAnnotations implementation from Csla.Wp, because WinRT doesn’t have DataAnnotations
  3. WinRT is also missing both INotifyDataErrorInfo and IDataErrorInfo – so it isn’t clear how any validation errors can be reported to the UI from a business object (I hope they have some solution)
  4. I still need to add the WCF data portal service reference to the Csla.WinRT project, but it appears that the data portal is essentially the same as in SL

What remains are a couple relatively big issues that require some research:

  1. The BackgroundWorker component doesn’t exist in WinRT, and we’ll need to either rewrite it or switch everything to the new async/await model
  2. The .NET Type type is quite different in WinRT, so a lot of MethodCaller code needs to be changed to use the new WinRT type system

The MethodCaller issue is, I suspect, just a matter of learning and using the new type system. But this reveals an interesting fact: anyone using System.Reflection in their code (even for simple things) is probably going to need to make changes to move to WinRT.

The BackgroundWorker issue is more interesting. At first glance it seems obvious that we’d want to move to the async/await model. And I would – except that this model doesn’t exist in .NET 4, Silverlight 4, Silverlight 5, WP7, or WP7.5.

Silverlight 5 and WP7.5 are the challenges here, because they’ll be widely used concurrently with .NET 4.5 and WinRT over a period of months or years.

  1. If we require the use of async/await, then CSLA 4.5 could not support SL 5 or WP7.5 (this violates one of the key value statements of CSLA .NET)
  2. If we use async/await in .NET/WinRT, then you can’t have compatible object code between .NET/WinRT and SL/WP (this violates one of the key value statements of CSLA .NET)
  3. If we re-implement BackgroundWorker in WinRT, then CSLA and your business code is unaffected, but you won’t be able to use async/await when you interact with the async data portal or async business rules
  4. If we support the use of async/await on .NET/WinRT, but also support BackgroundWorker then you get to choose whether to write cross-compatible code, or code that works on 4.5/WinRT only

Clearly options 1 and 2 won’t work. So we have to explore re-implementing BackgroundWorker in WinRT. Presumably we’ll use async/await inside our BackgroundWorker replacement, but we’ll keep the external interface consistent. I hope this is possible – I’m just thinking out loud at this point.

In the medium timeframe option 4 has to be the goal. In the long run I think it is safe to assume that some future version of SL and some future version of Windows Phone will support async/await. When all the then-current Microsoft platforms support the model we’ll drop BackgroundWorker entirely.

Regardless, I am quite pleased by just how far I was able to get in just a couple hours work. I have the Csla.WinRT project structure in place, and have narrowed down the problem areas to:

  1. We need some validation error notification model to replace IDEI and INDEI
  2. We need a BackgroundWorker replacement
  3. We need a MethodCaller update

When you think about the breadth of scope of the CSLA 4 framework, I’m pretty amazed that we only have three problem areas to address for the core framework.

We’ll also need to create a Csla.Xaml.WinRT assembly with some UI helpers (that’s probably how we’ll solve the validation error issue for example). I haven’t explored how much of the existing Csla.Xaml concepts will carry forward – but I suspect Csla.Xaml.WinRT will be very much like the existing Csla.Xaml.Wp project.

Sunday, September 18, 2011 8:36:28 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Saturday, September 17, 2011

At //build/ this past week I heard numerous people suggest that WinRT and Metro aren’t going to be used for business app development. That Metro is for consumer apps only. These comments were from Microsoft and non-Microsoft people.

They could be right, but I think they are wrong.

Let’s think forward about 5 years, and assume that Win8 has become quite successful in the consumer space with Metro apps. And let’s remember that consumers are the same people who use computers in the corporate world.

Then let’s think back to the early 1990’s, when most corporate apps were 3270 or VT100 green-screen terminals, and what people used at home (or even at work for other apps like Lotus 123 or maybe Excel) was Windows.

Users back then pushed hard for Windows interfaces for everything. Compared to the green-screen terminals, Windows was a breath of fresh air, and users really wanted to get away from the terminal experience.

Metro is to today’s Windows, what Windows was to terminals. A smooth, touch-based interface that encourages more intuitive and aesthetically pleasing user experiences. And the extremely popular iPad interface is similar.

In 5 years I strongly suspect that users will be pushing hard for Metro interfaces for everything. The old-fashioned, legacy Windows look (because that’s what it will be) will be extremely undesirable.

In fact I would suggest it is already uncool, especially in the face of iPad apps that exist today.

Windows computers are … computers.

iPad devices are friendly companions on people’s individual journeys through life.

(and so are Windows Phone devices – my phone is not a computing device, it is an integral part of my life)

Windows 8 and Metro gives us the opportunity to build apps that fit into something that is an integral part of people’s lives.

Because most people spend at least half their waking life at work, it seems obvious that they’ll want their work apps to be just as smooth and seamless as all the other apps they use.

In short, my prediction is that 5 years from now there’ll be “legacy Windows developers” still building stuff that runs in the clunky desktop mode. And there’ll be “modern Windows developers” that build stuff that runs in Metro – and a lot of those Metro apps will be business applications.

Will we make Jensen (the Microsoft keynote speaker pushing the vision of Metro) happy with every one of these business apps? Will they all fit exactly into the “Metro style”?

I doubt it.

But games don’t either. Metro games take over the whole screen and do whatever they want in the space. And nobody complains that they break the Metro style rules.

Some data-heavy business apps will also break the Metro style rules – I pretty much guarantee it. And yet they’ll still run in the Metro mode, and thus will run on ARM as well as Intel chips, and won’t require the user to see the clunky desktop mode.

In 5 years we can all check back on this blog post to see if I’m right. But I strongly suspect that 5 years from now I’ll be having a great time building some cool Metro business app Smile

Saturday, September 17, 2011 10:52:48 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, September 16, 2011

Microsoft revealed quite a lot of detail about "Windows 8" and its programming model at the //build/ conference in September 2011. The result is a lot of excitement, and a lot of fear and worry, on the part of Microsoft developers and customers.

From what I've seen so far, in reading tweets and other online discussions, is that people's fear and worry are misplaced. Not necessarily unwarranted, but misplaced.

There's a lot of worry that ".NET has no future" or "Silverlight has no future". These worries are, in my view, misplaced.

First, it is important to understand that the new WinRT (Windows Runtime) model that supports Win8 Metro style apps is accessible from .NET. Yes, you can also use C++, but I can't imagine a whole lot of people care. And you can use JavaScript, which is pretty cool.

But the important thing to understand is that WinRT is fully accessible from .NET. The model is quite similar to Silverlight for Windows Phone. You write a program using C# or VB, and that program runs within the CLR, and has access to a set of base class libraries (BCL) just like a .NET, Silverlight, or WP7 app today. Your program also has access to a large new namespace where you have access to all the WinRT types.

These WinRT types are the same ones used by C++ or JavaScript developers in WinRT. I think this is very cool, because it means that (for perhaps the first time ever) we'll be able to create truly first-class Windows applications in C#, without having to resort to C++ or p/invoke calls.

The BCL available to your Metro/WinRT app is restricted to things that are "safe" for a Metro app to use, and the BCL features don't duplicate what's provided by the WinRT objects. This means that some of your existing .NET code won't just compile in WinRT, because you might be using some .NET BCL features that are now found in WinRT, or that aren't deemed "safe" for a Metro app.

That is exactly like Silverlight and WP7 apps. The BCL features available in Silverlight or WP7 are also restricted to disallow things that aren't safe, or that make no sense in those environments.

In fact, from what I've seen so far, it looks like the WinRT BCL features are more comparable to Silverlight than anything else. So I strongly suspect that Silverlight apps will migrate to WinRT far more easily than any other type of app.

None of this gives me any real worry or concern. Yes, if you are a Windows Forms developer, and very possibly if you are a WPF developer, you'll have some real effort to migrate to WinRT, but it isn't like you have to learn everything new from scratch like we did moving from VB/COM to .NET. And if you are a Silverlight developer you'll probably have a pretty easy time, but there'll still be some real effort to migrate to WinRT.

If nothing else, we all need to go learn the WinRT API, which Microsoft said was around 1800 types.

So what should you worry about? In my view, the big thing about Win8 and Metro style apps is that these apps have a different lifetime and a different user experience model. The last time we underwent such a dramatic change in the way Windows apps worked was when we moved from Windows 3.1 (or Windows for Workgroups) to Windows 95.

To bring this home, let me share a story. When .NET was first coming out I was quite excited, and I was putting a lot of time into learning .NET. As a developer my world was turned upside down and I had to learn a whole new platform and tools and langauge - awesome!! :)

I was having a conversation with my mother, and she could tell I was having fun. She asked "so when will I see some of this new .NET on my computer?"

How do you answer that? Windows Forms, as different as it was from VB6, created apps that looked exactly the same. My mother saw exactly zero difference as a result of our massive move from VB/COM to .NET.

Kind of sad when you think about it. We learned a whole new programming platform so we could build apps that users couldn't distinguish from what we'd been doing before.

Windows 8 and Metro are the inverse. We don't really need to learn any new major platform or tools or languages. From a developer perspective this is exciting, but evolutionary. But from a user perspective everything is changing. When I next talk to my mother about how excited I am, I can tell her (actually I can show her thanks to the Samsung tablet - thank you Microsoft!) that she'll see new applications that are easier to learn, understand, and use.

This is wonderful!!

But from our perspective as developers, we are going to have to rethink and relearn how apps are designed at the user experience and user workflow level. And we are going to have to learn how to live within the new application lifecycle model where apps can suspend and then either resume or be silently terminated.

Instead of spending a lot of time angsting over whether the WinRT CLR or BCL is exactly like .NET/Silverlight/WP7, we should be angsting over the major impact of the application lifecycle and Metro style UX and Metro style navigation within each application.

OK, I don't honestly think we should have angst over that either. I think this is exciting, and challenging. If I wanted to live in a stable (stagnant?) world where I didn't need to think through such things, well, I think I'd be an accountant or something…

Yes, this will take some effort and some deep thinking. And it will absolutely impact how we build software over the next many years.

And this brings me to the question of timing. When should we care about Metro and WinRT? Here's a potential timeline, that I suspect is quite realistic based on watching Windows releases since 1990.

Win8 will probably RTM in time for hardware vendors to create, package, and deliver all sorts of machines for the 2012 holiday season. So probably somewhere between July and October 2012.

For consumer apps this means you might care about Win8 now, because you might want to make sure your cool app is in the Win8 online store for the 2012 holiday season.

For business apps the timing is quite different. Corporations roll out a new OS much later than consumers get it through retailers. As an example, Windows 7 has now been out for about three years, but most corporations still use Windows XP!!! I have no hard numbers, but I suspect Win7 is deployed in maybe 25% of corporations - after being available for three years.

That is pretty typical.

So for business apps, we can look at doing a reasonable amount of Win8 Metro development around 2015.

Yes, some of us will be lucky enough to work for "type A" companies that jump on new things as they come out, and we'll get to build Metro apps starting in late 2012.

Most of us work for "type B" companies, and they'll roll out a new OS after SP1 has been deployed by the "type A" companies - these are the companies that will deploy Win8 after has been out for 2-4 years.

Some unfortunate souls work for "type C" companies, and they'll roll out Win8 when Win7 loses support (so around 2018?). I used to work for a "type C" company, and that's a hard place to find yourself as a developer. Yet those companies do exist even today.

What does this all mean? It means that for a typical corporate or business developer, we have around 4 years from today before we're building WinRT apps.

The logical question to ask then (and you really should ask this question), is what do we do for the next 4 years??? How do we build software between now and when we get to use Metro/WinRT?

Obviously the concern is that if you build an app starting today, how do you protect that investment so you don't have to completely rewrite the app in 4 years?

I don't yet know the solid answer. We just don't have enough deep information yet. That'll change though, because we now have access to early Win8 builds and early tooling.

What I suspect is that the best way to mitigate risk will be to build apps today using Silverlight and the Silverlight navigation model (because that's also the model used in WinRT).

The BCL features available to a Silverlight app are closer to WinRT than full .NET is today, so the odds of using BCL features that won't be available to a Metro app is reduced.

Also, thinking through the user experience and user workflow from a Silverlight navigation perspective will get your overall application experience closer to what you'd do in a Metro style app - at least when compared to any workflow you'd have in Windows Forms. Certainly you can use WPF and also create a Silverlight-style navigation model, and that'd also be good.

Clearly any app that uses multiple windows or modal dialogs (or really any dialogs) will not migrate to Metro without some major rework.

The one remaining concern is the new run/suspend/resume/terminate application model. Even Silverlight doesn't use that model today - except on WP7. I think some thought needs to go into application design today to enable support for suspend in the future. I don't have a great answer right at the moment, but I know that I'll be thinking about it, because this is important to easing migrations in the future.

It is true that whatever XAML you use today won't move to WinRT unchanged. Well, I can't say that with certainty, but the reality is that WinRT exposes several powerful UI controls we don't have today. And any Metro style app will need to use those WinRT controls to fit seamlessly into the Win8 world.

My guess is that some of the third-party component vendors are well on their way to replicating the WinRT controls for Silverlight and WPF today. I surely hope so anyway. And that's probably going to be the best way to minimize the XAML migration. If we have access to controls today that are very similar to the WinRT controls of the future, then we can more easily streamline the eventual migration.

In summary, Windows 8, WinRT, and Metro are a big deal. But not in the way most people seem to think. The .NET/C#/CLR/BCL story is evolutionary and just isn't that big a deal. It is the user experience and application lifecycle story that will require the most thought and effort as we build software over the next several years.

Personally I'm thrilled! These are good challenges, and I very much look forward to building .NET applications that deeply integrate with Windows 8. Applications that I can point to and proudly say "I built that".

Update: here are a couple related blog posts from fellow Microsoft RDs:

and a good post from Doug Seven:

and from fellow Magenic experts:

Friday, September 16, 2011 8:27:24 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
On this page....
Third Party Dev Tools Strike Back
Sharing Code from WinForms to iOS
CSLA 4 version 4.5.600 release with iOS support
Limitations of Portable Class Libraries
Return of the Start menu is low priority to me
Windows 8 side loading improvements
Defining disservice
Top Win8/WinRT apps
Does .NET Have A Future?
WinRT as the new Silverlight and WPF
Thoughts on Build 2013
Good Windows 8 sales
Windows 8 WinRT licensing ideas
Windows 8 WinRT sideloading update
Testing a WinRT app on a Surface RT
Silverlight is “dead”
Can you run WinRT apps on Win7?
CSLA 4 version 4.5 released with support for WinRT
Implementing an async rule in CSLA 4 version 4.5
CSLA 4 version 4.5 beta 1 released
Side-loading on Windows 8
VS Live Windows 8 SkyDrive talk
Windows 8 Terminology and Concepts
CSLA data portal changes in version 4.5
Why Windows 8 is so important
Microsoft Windows 8 Surface
Set rich text into RichTextBlock control
Using the MVVM pattern requires a framework
Should I learn Silverlight? Objective C? HTML 5?
No BindingExpression in WinRT?
Windows 8, Start Screen, Multi-Monitor Usability
Windows Forms to Windows Runtime
Early findings going from Silverlight to WinRT
Allowing a WinRT app to do loopback network calls
Why I want Windows 8 on my PC
Windows 8 on a laptop
Windows 8 and enterprise app dev strategy
Windows 8 CP install experience
Windows 8 and WinRT development whitepaper
Improving CSLA 4 MobileFormatter behavior
Web sites vs Web apps
Silverlight 6 doesn’t matter
Updated Win 8 Dev Platform diagram
Windows 8 blog summary
Windows 8 Development Platform Clarified
Magenic interviews at Build11
Win8, Metro, and WinRT terminology
WinRT BackgroundWorker type
Migrating smart clients to WinRT
CSLA on WinRT (project start)
WinRT and business apps
WinRT and .NET
Feed your aggregator (RSS 2.0)
April, 2019 (2)
January, 2019 (1)
December, 2018 (1)
November, 2018 (1)
October, 2018 (1)
September, 2018 (3)
August, 2018 (3)
June, 2018 (4)
May, 2018 (1)
April, 2018 (3)
March, 2018 (4)
December, 2017 (1)
November, 2017 (2)
October, 2017 (1)
September, 2017 (3)
August, 2017 (1)
July, 2017 (1)
June, 2017 (1)
May, 2017 (1)
April, 2017 (2)
March, 2017 (1)
February, 2017 (2)
January, 2017 (2)
December, 2016 (5)
November, 2016 (2)
August, 2016 (4)
July, 2016 (2)
June, 2016 (4)
May, 2016 (3)
April, 2016 (4)
March, 2016 (1)
February, 2016 (7)
January, 2016 (4)
December, 2015 (4)
November, 2015 (2)
October, 2015 (2)
September, 2015 (3)
August, 2015 (3)
July, 2015 (2)
June, 2015 (2)
May, 2015 (1)
February, 2015 (1)
January, 2015 (1)
October, 2014 (1)
August, 2014 (2)
July, 2014 (3)
June, 2014 (4)
May, 2014 (2)
April, 2014 (6)
March, 2014 (4)
February, 2014 (4)
January, 2014 (2)
December, 2013 (3)
October, 2013 (3)
August, 2013 (5)
July, 2013 (2)
May, 2013 (3)
April, 2013 (2)
March, 2013 (3)
February, 2013 (7)
January, 2013 (4)
December, 2012 (3)
November, 2012 (3)
October, 2012 (7)
September, 2012 (1)
August, 2012 (4)
July, 2012 (3)
June, 2012 (5)
May, 2012 (4)
April, 2012 (6)
March, 2012 (10)
February, 2012 (2)
January, 2012 (2)
December, 2011 (4)
November, 2011 (6)
October, 2011 (14)
September, 2011 (5)
August, 2011 (3)
June, 2011 (2)
May, 2011 (1)
April, 2011 (3)
March, 2011 (6)
February, 2011 (3)
January, 2011 (6)
December, 2010 (3)
November, 2010 (8)
October, 2010 (6)
September, 2010 (6)
August, 2010 (7)
July, 2010 (8)
June, 2010 (6)
May, 2010 (8)
April, 2010 (13)
March, 2010 (7)
February, 2010 (5)
January, 2010 (9)
December, 2009 (6)
November, 2009 (8)
October, 2009 (11)
September, 2009 (5)
August, 2009 (5)
July, 2009 (10)
June, 2009 (5)
May, 2009 (7)
April, 2009 (7)
March, 2009 (11)
February, 2009 (6)
January, 2009 (9)
December, 2008 (5)
November, 2008 (4)
October, 2008 (7)
September, 2008 (8)
August, 2008 (11)
July, 2008 (11)
June, 2008 (10)
May, 2008 (6)
April, 2008 (8)
March, 2008 (9)
February, 2008 (6)
January, 2008 (6)
December, 2007 (6)
November, 2007 (9)
October, 2007 (7)
September, 2007 (5)
August, 2007 (8)
July, 2007 (6)
June, 2007 (8)
May, 2007 (7)
April, 2007 (9)
March, 2007 (8)
February, 2007 (5)
January, 2007 (9)
December, 2006 (4)
November, 2006 (3)
October, 2006 (4)
September, 2006 (9)
August, 2006 (4)
July, 2006 (9)
June, 2006 (4)
May, 2006 (10)
April, 2006 (4)
March, 2006 (11)
February, 2006 (3)
January, 2006 (13)
December, 2005 (6)
November, 2005 (7)
October, 2005 (4)
September, 2005 (9)
August, 2005 (6)
July, 2005 (7)
June, 2005 (5)
May, 2005 (4)
April, 2005 (7)
March, 2005 (16)
February, 2005 (17)
January, 2005 (17)
December, 2004 (13)
November, 2004 (7)
October, 2004 (14)
September, 2004 (11)
August, 2004 (7)
July, 2004 (3)
June, 2004 (6)
May, 2004 (3)
April, 2004 (2)
March, 2004 (1)
February, 2004 (5)

Powered by: newtelligence dasBlog 2.0.7226.0

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2019, Marimer LLC

Send mail to the author(s) E-mail

Sign In