Rockford Lhotka

 Saturday, September 17, 2011

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

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

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

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

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

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

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

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

Windows computers are … computers.

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

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

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

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

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

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

I doubt it.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This is wonderful!!

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

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

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

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

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

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

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

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

That is pretty typical.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

and a good post from Doug Seven:

and from fellow Magenic experts:

Friday, September 16, 2011 8:27:24 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, August 29, 2011

One of the most impressive benefits of working for Magenic is that at the 10 year mark they offer a three month sabbatical to employees. I just finished my sabbatical, right as I crossed the 11 year mark working for Magenic.

I’ve spent the past three months not being immersed in computers, software development, industry intrigue/rumor, or speculation about the future of <insert your company/technology here>.

Instead, I was camping, fishing, waterskiing, reading (a book on how the brain works, and a bunch of fiction), and spending tons of time with my wife and kids.

I find that I am quite refreshed. When the sabbatical started, I was in a state of angst. Microsoft was making noises about HTML 5 being the future, casting doubt on the future of .NET and Silverlight, and really throwing some doubt on the viability of Microsoft as a company.

Those doubts still exist – and we’ll find out whether Microsoft is planning to undermine their entire developer base in just a couple weeks (at the BUILD conference).

But after a few months of not worrying about these things I realize they just aren’t important. Not in the long run.

For the first several years of my career I was a DEC VAX/OpenVMS expert. Programmer, system administrator, hardware geek. I knew the ins and outs of the operating system, hardware, networking – everything. It was fun to have that level of expertise and knowledge – to literally know no bounds.

But DEC went from being the number 2 computer maker in the world to a footnote in about 3 years. In 1993-4 they were big. By 1997 most people had never really heard of them. Of course in that timeframe they’d been purchased by Compaq.

And that is what has me thinking about this – because HP bought Compaq, and now HP could easily be imploding such that they’ll be nothing but a footnote a couple years from now. In fact, even Google, Microsoft, Apple, and Amazon are all just 3 years from being forgotten at any point in time.

What is interesting, is that none of my direct VAX or OpenVMS skills translated into the Windows world (because that’s where I went back then). The important thing to understand is that my computer science skills, and my business-to-computer analyst skills translated. All that deep technical knowledge of OpenVMS became useless trivia almost overnight, but the foundation of my career remained intact.

I never gained the deep understanding of Windows I had with OpenVMS. I have no idea how to configure Windows enterprise domain networks, and can barely configure my home network. But I haven’t missed that type of knowledge (much), because I’ve been able to spend years focusing on software development – and that’s a lot more fun for me.

Around the turn of the century/millennium we got .NET. If we hadn’t have gotten .NET I’d have gone to Java (and I suspect almost everyone else would have too). The VB/COM/C++/ATL platform had gone as far as it could go at the time – we could create great apps, but they couldn’t be deployed due to coupling and DLL hell.

Few of my Windows/VB1-6 skills translated to .NET. The deep technical knowledge of VB and the Win32 API became useless trivia almost overnight. But again, the computer science and analyst skills, along with a lot of good architecture skills/knowledge carried through intact.

The past decade working in .NET has been one of pure joy. I truly love .NET – even more than I loved VB in the 90’s and OpenVMS in the 80’s. But let’s face it, the future of .NET really is an unknown at this point.

If BUILD is all about HTML 5, JavaScript, and C++, then .NET is de facto dead on the client, and will probably suffer a slow but sure death on the server too.

On the other hand, if .NET has a substantial place for creating first-class Win8 apps, then we can all resume our normally scheduled lives.

I should clarify: by “.NET” I mean anything from actual .NET to “native Silverlight” like on WP7 to something-like-Silverlight-but-tailored-for-Win8. My personal vote is for something like Silverlight on WP7, but tailored for Win8.

In the end, the worst case is that Microsoft decides to treat .NET as a second-class technology on Win8, so it can only create “legacy mode” applications. That would effectively make all our deep knowledge of .NET into useless trivia overnight, because we couldn’t use any of our existing skills to build first-class Win8 apps.

I must say, that this “end of .NET” scenario would be the first platform shift where I felt like the industry was going backwards. Going from the VAX to VB was fun. Going from VB to .NET was even more fun. But somebody is going to have to pull a pretty amazing rabbit out of their hat to make HTML 5 and JavaScript look like fun compared to .NET… Whether that’s Google, Apple, Amazon, or Microsoft – I haven’t seen them come up with anything yet that has me looking forward to such a future.

But platform shifts happen. Vendors come and go, operating systems and development platforms come and go, but we always have our computer science and real-world analyst skills because they are independent of any given platform. In the long run, the survival of .NET, or even Microsoft, isn’t a given – but each of us will continue to have a career, and we’ll continue to build software that makes the world (or at least our little piece of it) a better place.

Personally, I maintain hope that BUILD will be the place where Microsoft reveals .NET “” with all sorts of cool support for Win8 application development. I’ll find out if I’m right in just two weeks Smile

Monday, August 29, 2011 3:34:49 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, August 22, 2011

VVSLRED Speaker Button_Lhotkaisual Studio Live is coming to Redmond in October.

As one of the conference chairs, and a speaker at the event, I highly recommend this show. We have a great lineup of speakers and topics that provide practical information you can use today, and content that will help you plan for the future.

When you register, use code VRSPK23 to save $400, and make note of the September 7 early bird pricing deadline.

Monday, August 22, 2011 5:18:17 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, August 5, 2011

I use Facebook, quite a lot actually. But over time I’ve changed how I use it.

I used to friend anyone who asked. So I had a lot of friends (probably close to a couple thousand). Most of whom I didn’t actually know.

Of course if you actually use FB, you post things about family, friends, politics, religion, etc. Things you might not want to share with prospective customers, vendors, or random strangers.

So a while ago I created two public pages:

  • – a page you can “Like” if you want periodic updates on my professional activities and my editorial thoughts on the software development industry
  • – a page you can “Like” if you want periodic updates on CSLA .NET, and related things like ebooks and videos

After creating those pages, I went through and removed lots of “friends” from my personal FB page. If I didn’t look at a name and immediately know who the person was, I removed that person. This means I’m still friended to a lot of pretty casual friends – more like acquaintances – but at least I’m not friends with total strangers.

This arrangement is much better. Now I can post about professional stuff on my professional pages. And I can post about non-professional stuff in a venue visible to people who (presumably) care about my favorite foods, the lives of my children, etc.

If you are one of the scores of people who’ve requested that I friend you – and you are wondering why I ignored the request – now you know Smile  Please go “Like” one or both of the professional pages listed above to keep in touch – thanks!

(as an aside, I do sometimes use twitter at – and that’s a total mix of personal and professional babble – exactly what twitter is meant for I think)

Friday, August 5, 2011 12:03:33 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, June 15, 2011

The servers hosting the various sites (,,,, etc.) are being physically moved this weekend.

The sites will be down for hours during June 17-19.

Please refer to for status updates during this weekend.

Thank you for your understanding!

Wednesday, June 15, 2011 4:26:59 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, June 7, 2011

The final draft of the Using CSLA 4: ASP.NET MVC ebook is now online, and available for purchase.

If you own the Using CSLA 4 ebook series, you already own this new ebook and can download it from

If you are buying the ebooks individually, the new book is now available for purchase from

This ebook also includes a code download, containing the latest ProjectTracker codebase. This includes the Mvc3UI project: an ASP.NET MVC 3 application built using the CSLA .NET business layer.

Books | CSLA .NET | Web
Tuesday, June 7, 2011 3:50:00 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, May 4, 2011

I am pleased to announce that the Using CSLA 4: Data Portal Configuration ebook is available for purchase in draft form.

Owners of the Using CSLA 4 ebook series can also download the updated ebook draft.

This ebook (141 pages in PDF format) covers the use of the CSLA 4 data portal technology, which enables flexible n-tier deployments of your applications in 1-, 2-, 3- and 4-tier physical configurations. The ebook covers the use of the data portal in .NET smart client, Silverlight, WP7, and ASP.NET web applications.

The ebook also covers the authentication techniques supported by CSLA .NET, including Windows integrated domain or Active Directory authentication, the use of the ASP.NET MembershipProvider model and custom authentication against your own security data store.

The ebook includes a complete set of sample applications demonstrating the concepts and techniques discussed in the book.

Here is a high level list of the content in this ebook:

  1. Data Portal Deployment
    1. Data portal concepts
    2. Deployment options
    3. Using the local channel
    4. Using the WCF channel
    5. 4-tier Silverlight and WP7 deployment
  2. Data portal configuration reference
  3. Serialization
    1. .NET serialization
    2. MobileFormatter
  4. Custom data portal proxies
    1. Supporting multiple application servers
    2. Dynamically switching between online and offline mode
  5. Authentication models
    1. Custom authentication
    2. ASP.NET membership authentication
    3. Windows authentication
Wednesday, May 4, 2011 9:18:41 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, April 28, 2011

Today I spent hours trying to make one line of code work. Fortunately Miguel Castro was ultimately able to help me troubleshoot the issue thanks to his deep understanding of all things ASP.NET.

The line of code seems so simple:

var data = Roles.GetRolesForUser(“rocky”);

In this case Roles is the RoleProvider API from System.Web.Security, and the method returns a string array with the roles for the user.

This line of code works great in my aspx page. No problem at all.

But in the same web project it throws a NullReferenceException when called from a WCF service (in a svc).

No stack trace. No detail. No nothing. I Binged, and Googled, and created a whole new solution (figuring my first solution was somehow corrupted). But nothing helped.

To cut to the answer, this works in a WCF service:

var data = Roles.Provider.GetRolesForUser(“rocky”);

See the difference? Instead of relying on the static helper method on the Roles type, this code explicitly calls the method on the default provider instance.

(fwiw, I think this behavior is relatively new, because that code used to work. I just don’t remember how long ago it was that it worked – .NET 3 or 3.5 – so perhaps something broke in .NET 4?)

In any case, problem solved – thanks Miguel!!

WCF | Web
Thursday, April 28, 2011 5:46:57 PM (Central Standard Time, UTC-06:00)  #    Disclaimer