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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thus far I’ve accumulated some requirements:

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

No per-device fees

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

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

Multiple marketplaces

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

Public marketplaces

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

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

Work from home

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

No InTune requirement

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

The result

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

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

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

1. http://www.lhotka.net/weblog/CostToEnableSideloadingOnAWindows8Device.aspx
2. http://www.lhotka.net/weblog/Windows8LOBDeploymentLsquostoryrsquo.aspx
3. http://www.lhotka.net/weblog/PerspectivesOnWinRTAppLicensing.aspx

As a result of this two things have happened.

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

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

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

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

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

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

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

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

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

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

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

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

In short:

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

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

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

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

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

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

Creating the Package

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

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

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

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

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

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

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

Unlocking PowerShell

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

Set-ExecutionPolicy unrestricted

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

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

Installing the App

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

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

The script will ask permission to run.

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

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

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

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

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

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

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

http://www.zdnet.com/microsoft-pulls-the-plug-on-its-silverlight-net-site-7000008494/

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

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

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

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

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

Obviously there’s a fine line here.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Wikipedia page describing the Win8 editions is highly misleading:

http://en.wikipedia.org/wiki/Windows_8_editions

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

The following two links provide important details:

• Deploying Metro Apps to Businesses
• How to Add and Remove Apps

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

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

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

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

The LivePush project is here on SkyDrive:

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

Here are some of the basic terms:

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

Windows 8 basically includes two different operating systems.

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

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

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

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

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

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

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

	Technologies	Platforms
Full .NET 4.5	ASP.NET, WPF, Windows Forms, WCF, WF	Windows 7, Windows 8 Desktop, Windows Server 2008, Windows Server 2012
WinRT .NET 4.5	Windows 8 UI style apps	Windows 8 WinRT, Windows Phone 8, rumored for next-gen Xbox
Full .NET 4	ASP.NET, WPF, Windows Forms, WCF, WF	Windows 7, Windows Server 2008, Azure PaaS
Silverlight	Silverlight	Windows 7, Windows 8 Desktop, Windows Phone 7, Windows Phone 8

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

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

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

All four have some level of breaking change.

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

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

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

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

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

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

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

private void DataPortal_Fetch(int id)

or like this

private async Task DataPortal_Fetch(int id)

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

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

var obj = await CustomerEdit.GetCustomerAsync(123);

or the older event-style code:

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

Only .NET code can use the synchronous approach:

var obj = CustomerEdit.GetCustomer(123);

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

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

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

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

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

var obj = await CustomerEdit.GetCustomerAsync(123);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://www.microsoft.com/surface/en/us/default.aspx

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/