Rockford Lhotka

 Friday, August 3, 2012

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

Here are some of the basic terms:

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

Windows 8 basically includes two different operating systems.

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

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

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

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

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

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

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

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

Check out the new logo graphics for CSLA 4 version 4.5!

Thank you to Sandra Fougerousse for creating these updated Windows 8 style logo graphics!

csla win8

For those who are wondering, I expect to put a beta of version 4.5 online shortly after August 15 (when Windows 8 and Visual Studio 2012 final bits are available). That will start the beta cycle, with a planned release of version 4.5 around the end of October (if not sooner). I’m very exited to get CSLA .NET for WinRT into the hands of app developers!

Wednesday, August 1, 2012 10:45:32 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, July 30, 2012

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

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

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

All four have some level of breaking change.

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

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

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

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

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

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

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

private void DataPortal_Fetch(int id)

or like this

private async Task DataPortal_Fetch(int id)

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

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

var obj = await CustomerEdit.GetCustomerAsync(123);

or the older event-style code:

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

Only .NET code can use the synchronous approach:

var obj = CustomerEdit.GetCustomer(123);

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

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

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

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

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

var obj = await CustomerEdit.GetCustomerAsync(123);

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

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

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

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

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

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

In a word: yes.

My post is spurred by discussions I’ve had around this recent article:,16190.html#xtor=RSS-998

And my post is motivated by the fact that I’ve had an i5-based Windows 8 tablet for a few months now, and have direct experience with the idea of using a tablet as a desktop/laptop replacement.

First, understand that I have:

  • A tablet with an i5 CPU, a decent GPU, 4 gb RAM, and an SSD
  • A docking station for the tablet with USB and HDMI ports
  • A bluetooth keyboard
  • A bluetooth mouse

On this tablet I have installed:

  • A variety of WinRT/Metro style apps
  • Office 2010
  • Visual Studio 2012
  • Expression Blend
  • Microsoft Lync
  • DropBox and the Win7 SkyDrive client

Second, understand that I also have a high-end desktop (for dev work and gaming), and an i7-based laptop for dev work. The laptop is also running Win8, and the desktop is still Win7.

Third, I’m a big guy. I’m 6’5” tall, with broad shoulders, and big hands. Netbook keyboards are a joke, nearly useless. Normal laptop keyboards cause me great wrist, arm, and shoulder pain. Only Microsoft Natural keyboards allow me to type for any length without discomfort.

Given that background, here’s my normal usage profiles.

My Home Office

I use my desktop for most things, because it is all set up with a Microsoft Natural keyboard and multiple monitors. It is just comfortable, and all my games are installed on this machine, as is VS10 for work on .NET 3.5 stuff.

Also I’m a gamer, and I have a friend who custom-builds my desktop computers. So I always have a top-end dev/gaming rig for a fraction of the cost to get a comparable laptop. And I have yet to see anyone talking about a “gaming capable” tablet – not at the level of gaming oriented tablets or desktops. Were there to be a tablet that could run Battlefield 3 at high res and no lag, AND without me needing a second mortgage on my house, I’d consider getting rid of my desktop.

My Magenic Office

I use my laptop (Win8) for most things, because I have a nice docking station connected to multiple monitors and a Natural keyboard. My laptop also has Office, VS10, and VS12, so I can do whatever work I need, plus it has a variety of WinRT apps that I use on a regular basis (mostly the same apps as on the tablet).

I could use my tablet instead, but the Dell docking station for my laptop is somewhat more convenient than the docking station for the tablet. This is because I carry the tablet’s docking station with me everywhere. If I bought a second docking station to leave in my office then I’d probably just use the tablet instead of the laptop.

On the road

When I’m on the road there’s no access to a Natural keyboard, so I have wrist, arm, and shoulder pain. This is true with my laptop keyboard and the bluetooth tablet keyboard. They are both too small for me, but it isn’t realistic to carry a “real” keyboard around everywhere. So I put up with the pain and minimize the amount of typing work I do while traveling. Tai Chi helps too.

Over the past few months, I have taken to only carrying my tablet while on the road. Because I avoid doing extensive typing on the road, I also avoid doing extensive dev work. As a result, the difference between the i5 tablet and i7 laptop is pretty immaterial, and the tablet is a LOT lighter and easier to carry. It is also a lot more useful on the airplane (remember, I’m a big guy – even first class seats often have too little room to open my big laptop).

In short, while on the road, my tablet has become a complete laptop replacement.

At conferences

The one exception to the tablet replacing my laptop while on the road is when I go to conferences. The problem here isn’t probably what you’d expect: it is a video projection issue.

The tablet has HDMI out, and its docking station has HDMI out. No VGA out at all. I do have an HDMI to VGA converter (from HP) that usually works, but not always. If the sole purpose of my travel is to speak at a conference, you can imagine that it is bad if my computer can’t project onto the screen.

So I lug my laptop around specifically because it has a VGA output jack. Sad but true…

So in summary, once companies and conferences have a reliable way to project HDMI video content onto overhead screens, I’ll have no reason to carry my laptop at all anymore when on the road. And if I bought a second docking station to leave at my Magenic office I wouldn’t need my laptop there either – so I wouldn’t need the laptop at all.

The desktop is harder to give up because I’m a gamer, and there’s nothing on the horizon that would allow me to play my games on an affordable laptop, much less tablet.

Yes, laptops are doomed – tablets will replace them over the next few years – of that I have little doubt.

Desktops aren’t entirely doomed – at least for gamers, CAD users, people doing graphics work, and other scenarios where cost-effective high-end hardware is required. But even today few people have only a desktop. Most people have a desktop and laptop – and in the near future I expect they’ll have a desktop and tablet instead.

For me, I’m happy that my tablet is now my primary work machine. It works great, and meets my needs for everything except high end gaming.

Wednesday, July 11, 2012 12:25:10 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, July 3, 2012

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A co-worker of mine at Magenic is not only also a tabletop RPG gamer like me, but he’s working on a Google+ Hangout project to more easily play RPGs and other tabletop games with people from around the world.

To this end, he’s doing a Kickstarter

So if you are interested in this sort of thing, check it out and consider lending your support.

(As an aside for those who are interested, I’ve been playing tabletop RPGs since around 1979 or 80. Over the past 25+ years my group and I have developed our own gaming system, and have played in an internally consistent fantasy world. In game time we’ve spanned hundreds of years, and have told some wonderful stories. We’ve also played short bits in quite a few commercial gaming systems and settings, but we always return to our own system and world.)

Monday, June 11, 2012 1:03:17 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, June 7, 2012

I have put an early version of CSLA 4 version 4.5 (version 4.5.1) online. This is a stable alpha release that supports:

  • Microsoft .NET 4.5
  • WinRT Metro style apps on Windows 8
  • Silverlight 5

You can get it from the CSLA download page.

This version doesn’t currently support Windows Phone, mono, or Android because all work is being done using Visual Studio 2012. We’ll reintroduce support for those platforms as everything gets supported on VS12.

  • This 4.5 release has the same functionality as version 4.3.12, plus some functionality we’ve added only to 4.5. Most notably:
  • The .NET and WinRT data portal now supports the new async/await keywords through methods like CreateAsync and SaveAsync
        var obj = Csla.DataPortal.FetchAsync<CustomerEdit>(id);
  • The ViewModelBase class for WPF and WinRT now has an InitAsync method so you can await initialization of the viewmodel object
        var vm = await new MyViewModel().InitAsync();
  • Enhancements to business rule processing

See the 4.5 change log for more detail.

Because this is an alpha release, you should expect more changes as we improve support for .NET 4.5 (most notably ASP.NET Web Forms, MVC, and Web API), and for WinRT/Metro.

At the same time, this should be a reasonably stable release, especially on .NET where the platform is also stable. It is also reasonably stable on WinRT/Metro, though there are more changes involved there so there could be more bugs.

Please direct feedback to the CSLA forums.

Thursday, June 7, 2012 10:19:34 PM (Central Standard Time, UTC-06:00)  #    Disclaimer