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:

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

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();
      xaml.Append(@"
<UserControl
  xmlns=""http://schemas.microsoft.com/winfx/2006/xaml/presentation""
  xmlns:x=""http://schemas.microsoft.com/winfx/2006/xaml""
  xmlns:mc=""http://schemas.openxmlformats.org/markup-compatibility/2006"">
  <Grid>
    <RichTextBlock>");
      xaml.Append(ctl.Xaml);
      xaml.Append(@"
    </RichTextBlock>
  </Grid>
</UserControl>
");
      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…

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.

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?

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?

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?

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

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…

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.

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

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:

#if WINRT
    public async static System.Threading.Tasks.Task<ProjectList> GetProjectListAsync()
    {
      return await Csla.DataPortal.FetchAsync<ProjectTracker.Library.ProjectList>();
    }
#endif

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!

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 (127.0.0.1). The challenge and solution are described here:

http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx

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.
        CurrentUser.OpenSubKey("Software").
        OpenSubKey("Classes").
        OpenSubKey("Local Settings").
        OpenSubKey("Software").
        OpenSubKey("Microsoft").
        OpenSubKey("Windows").
        OpenSubKey("CurrentVersion").
        OpenSubKey("AppContainer").
        OpenSubKey("Mappings");

      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(app.GetValue("DisplayName"));
          Console.WriteLine("  SID:     " + item);
          Console.WriteLine("  Moniker: " + app.GetValue("Moniker"));
          Console.WriteLine();
        }
      }

      Console.ReadLine();
    }
  }
}

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

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

http://www.zdnet.com/blog/hardware/heres-whats-wrong-with-windows-8/19027?tag=nl.e539

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.

Why?

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”.

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.

Performance

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

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.

Close

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.

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.

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.

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.

http://magenic.com/Portfolio/WhitePaperWindows8DevelopmentPlatform.aspx

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.

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.

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

http://www.misfitgeek.com/2011/11/html5-app-versus-html5-page/

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.

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.

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.

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

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

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

WPF

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.

C++, MFC, ATL

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.

WinRT .NET and XAML

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.

WinRT HTML 5

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.

Summary

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!

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:

http://magenic.com/Portfolio/VideoBuildInterviews.aspx

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.

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:

http://www.lhotka.net/cslacvs/viewvc.cgi/core/trunk/Source/Csla.WinRT/Threading/BackgroundWorkerBCL.cs

//-----------------------------------------------------------------------
// <copyright file="BackgroundWorker.cs" company="Marimer LLC">
//     Copyright (c) Marimer LLC. All rights reserved.
//     Website: http://www.lhotka.net/cslanet/
// </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)
        _dispatcher.Invoke(CoreDispatcherPriority.Normal,
          (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()
    {
      RunWorkerAsync(null);
    }
 
    public async void RunWorkerAsync(object userState)
    {
      if (DoWork != null)
      {
        CancellationPending = false;
        IsBusy = true;
        try
        {
          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; }
  }
}

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.

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

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.

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

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:

• http://vinodunny.com/blog/post/Windows-8-Dev-Stacke28093My-take-on-it.aspx
• http://briannoyes.net/2011/09/15/SilverlightDevelopersHaveTheSmoothestRoadToMetro.aspx

and a good post from Doug Seven:

• http://dougseven.com/2011/09/15/a-bad-picture-is-worth-a-thousand-long-discussions/

and from fellow Magenic experts:

• http://dotnetspeak.com/index.php/2011/09/what-i-learned-at-the-build-conference/