Rockford Lhotka

 Thursday, February 14, 2013

In a recent email thread I ended up writing a lengthy bit of content summarizing some of my thoughts around the idea of automatically projecting js code into an HTML 5 (h5js) browser app.

Another participant in the thread mentioned that he’s a strong proponent of separation of concerns, and in particular keeping the “model” separate from data access. In his context the “model” is basically a set of data container or DTO objects. My response:


I agree about separation of concerns at the lower levels.

I am a firm believer in domain focused business objects though. In the use of “real” OOD, which largely eliminates the need for add-on hacks like a viewmodel.

In other words, apps should have clearly defined logical layers. I use this model:

Interface control
Data access
Data storage

This model works for pretty much everything: web apps, smart client apps, service apps, workflow tasks (apps), etc.

The key is that the business layer consists of honest-to-god real life business domain objects. These are designed using OOD so they reflect the requirements of the user scenario, not the database design.

If you have data-centric objects, they’ll live in the Data access layer. And that’s pretty common when using any ORM or something like EF, where the tools help you create data-centric types. That’s very useful – then all you need to do is use object:object mapping (OOM) to get the data from the data-centric objects into the more meaningful business domain objects.

At no point should any layer talk to the database other than the Data access layer. And at no point should the Interface/Interface control layers interact with anything except the Business layer.

Given all that, the question with smart client web apps (as I’ve taken to calling these weird h5js/.NET hybrids) is whether you are using a service-oriented architecture or an n-tier architecture. This choice must be made _first_ because it impacts every other decision.

The service-oriented approach says you are creating a system composed of multiple apps. In our discussion this would be the smart client h5js app and the server-side service app. SOA mandates that these apps don’t trust each other, and that they communicate through loosely coupled and clearly defined interface contracts. That allows the apps to version independently. And the lack of trust means that data flowing from the consuming app (h5js) to the service app isn’t trusted – which makes sense given how easy it is to hack anything running in the browser. In this world each app should (imo) consist of a series of layers such as those I mentioned earlier.

The n-tier approach says you are creating one app with multiple layers, and those layers might be deployed on different physical tiers. Because this is one app, the layers can and should have reasonable levels of trust between them. As a result you shouldn’t feel the need to re-run business logic just because the data flowed from one layer/tier to another (completely different from SOA).

N-tier can be challenging because you typically have to decide where to physically put the business layer: on the client to give the user a rich and interactive experience, or on the server for more control and easier maintenance. In the case of my CSLA .NET framework I embraced the concept of _mobile objects_ where the business layer literally runs on the client AND on the server, allowing you to easily run business logic where most appropriate. Sadly this requires that the same code can actually run on the client and server, which isn’t the case when the client and server are disparate platforms (e.g. h5js and .NET).

This idea of projecting server-side business domain objects into the client fits naturally into the n-tier world. This has been an area of deep discussion for months within the CSLA dev team – how to make it practical to translate the rich domain business behaviors into js without imposing a major burden of writing js alongside C#.

CSLA objects have a very rich set of rules and behaviors that ideally would be automatically projected into a js business layer for use by the smart client h5js Interface and Interface control layers. I love this idea – but the trick is to make it possible such that there’s not a major new burden for developers.

This idea of projecting server-side business domain objects into the client is a less natural fit for a service-oriented system, because there’s a clear and obvious level of coupling between the service app and the h5js app (given that parts of the h5js app literally generate based on the service app). I’m not sure this is a total roadblock, but you have to go into this recognizing that such an approach compromises the primary purpose of SOA, which is loose coupling between the apps in the system…

Thursday, February 14, 2013 10:39:23 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, February 8, 2013

The strangest thing happened this evening.

My wife’s best friend is visiting and we’re watching The Daily Show and the Colbert Report on the Xbox using Hulu Plus – catching up on our backlog of funny.

All of a sudden the TV goes blank, and then a picture appears on the screen. A picture from the friend’s phone.


So we stopped watching the shows and figured out what was going on (sort of).

She has a Samsung phone – one of the ones that is a “rip off” of the iPhone, so it is a pretty nice smart phone. And her phone is on our wifi.

When looking at a picture on her phone there’s a button at the top of the screen that, when tapped, sends the photo to the Xbox. It literally takes over the Xbox and shows the picture. And you can pan through pictures on the phone and they each appear on the Xbox (TV) – the images streaming from the phone to the Xbox.

On one hand this is pretty cool, and I wonder why my Windows Phone can’t do this?

On the other hand, it is a little scary to think that she was just playing around with her phone and was able (albeit accidentally) to hijack my Xbox.

Talk about a connected world!

Friday, February 8, 2013 11:21:54 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, February 6, 2013

I have released a beta of CSLA .NET: version 4.5.11, working toward a final release in a few weeks.

CSLA .NET is an open source software development framework that helps you build a reusable, scalable, and maintainable object-oriented business layer for your applications.

This update includes a few interesting features/changes.

  1. Adds support for Windows Phone 8 (WP8) development on the Windows Phone Runtime (WinPRT) platform
  2. Simplifies support for ASP.NET MVC 3 and ASP.NET MVC 4, as well as ADO.NET EF 4 and 5 by splitting functionality into separate assemblies and nuget packages
  3. Changes the local data portal to have the same behavior as a remote data portal for async calls; specifically this means that the local data portal automatically shifts all async requests onto a background thread from the thread pool
  4. Transactional attribute now allows you to set the isolation level
  5. Various bug fixes

You can get this prerelease version from nuget in Visual Studio, or you can download the new Wix-based installer from the CSLA download page.

Wednesday, February 6, 2013 5:36:07 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Sunday, February 3, 2013

Note that this is one post in a series. Make sure to read them all. This post provides an index to the set.

In my previous blog post I discussed the Windows 8 WinRT app licensing story for business apps. In that post I looked at the sideloading licensing model from a scenario-based perspective: large enterprise, medium, small, home user, developer/tester.

In this post I walk to explore a different way of thinking about the licensing. In fact, I think this is the core reason Microsoft’s licensing is so out of line with most of our expectations.

The core question: What is the primary competition Windows 8 faces?

Is it the iPad? Android tablets? Generally speaking BYOD.

Or is it WPF+ClickOnce, or HTML 5 and JavaScript? Generally speaking existing business app dev tools.

I’m increasingly confident that the Windows Division at Microsoft views the primary competitor as being BYOD. My evidence here is that Apple and the Android world do levy extra “taxes” for deployment of business apps to their devices. And they have built an ecosystem where additional infrastructure and tooling is required to manage mobile devices in an enterprise space. None of those things are free – hence everyone pays this “tax” to support BYOD in the enterprise.

Windows 8 appears to be following this model as well, by requiring extra licensing, infrastructure, and tools to support Windows devices in the enterprise. Basically Microsoft saw that people were willing to pay a BYOD tax on the other platforms and thought they’d be competitive by levying their own comparable tax for Windows 8. This makes pretty good business sense at one level, because it is a whole new revenue stream for Windows that hasn’t existed in the past.

The thing is, most existing Microsoft developers are looking at this new Windows 8 licensing/infrastructure and wondering what in the hell is going on???

We’ve spent the past 20 years or so building on the Microsoft platform from when it was a toy OS in the early 1990’s, to when it became an enterprise player in the 2000’s with .NET. Throughout all that time Microsoft’s licensing enabled us to easily build and deploy business apps on all Windows machines. No extra tax for business apps over consumer apps.

So now we’re looking at future app dev platform strategy. Where should we put our energy today so we’re best positioned into the future. And I’d suggest (coming from a Microsoft platform background) that we have three primary choices:

  1. Continue with WPF+ClickOnce in the hopes that Microsoft either continues to support Win32/.NET far into the future
  2. Switch to cross-platform HTML 5 and JavaScript to decouple from any specific client OS, including Windows
  3. Focus on Windows Runtime (WinRT) because it is clearly the future of the Microsoft client platform, even though they want to increase the costs of deployment to their platform

Nobody I know of is considering switching to iOS as their primary enterprise client platform. Nor are they looking at Android in that light. Hence Microsoft (imo) is making a major mistake by creating a BYOD-based licensing scheme for Windows 8, thinking their competition is iOS/Android, because what they are really doing is providing a financial dis-incentive for us to move to WinRT, and by extension a financial incentive for us to either stay on WPF or move to cross-platform HTML5.

Personally, having built a bunch of stuff for WinRT, I really, really, really wish Microsoft would drop this financial dis-incentive. I very much enjoy building WinRT apps with .NET. It is an absolute joy to finally be able to build a .NET/XAML app that integrates so smoothly and deeply into the Windows platform. Given a chance, I’ll absolutely embrace a WinRT-based future for smart client business app development!!

But assuming Microsoft maintains the current licensing model I think WPF or HTML5 are the more likely smart client business app dev platforms.

WPF+ClickOnce is really nice of course. It offers a great deployment model without any new license/infrastructure tax. Working in .NET/XAML is a true joy (imo anyway). And I think this is a great stop-gap approach if you assume Microsoft will fix the WinRT licensing story to eliminate the added deployment tax. Or if you assume Microsoft will waver in their focus on WinRT and will return to building on Win32.

I very much doubt they’ll return to any focus on Win32. I think that platform is now pure legacy. By extension WPF is also pure legacy (along with Silverlight and Windows Forms). So I don’t hold out any hope on that front.

I do hold out hope that Microsoft will fix the WinRT licensing story. They just need to realize that the primary competitor is HTML 5, not iOS.

So let’s talk about HTML5. From a Microsoft developer perspective switching to HTML5 as a smart client platform means complete retooling. Throw away all you know about C#/VB, the .NET framework, BCL, etc. Start over with HTML, CSS, and JavaScript, plus myriad open source JavaScript libraries. There is no “single platform” for HTML5 like there is for .NET – the “platform” varies radically depending on which particular open source libraries are chosen for any specific app dev effort. And those libraries are much more fluid and less predictable than the .NET platform, so it is virtually impossible to predict how they’ll evolve over a 3-5 year period, much less a 10 year period (which is a preferable planning horizon for an enterprise app).

As a result, the real costs of building and maintaining apps in HTML5 are way higher than in something like .NET. On the other hand, you get the ‘benefit’ of always living on the bleeding edge. This might make it easier to retain top dev talent, even while making it harder to build and maintain major enterprise apps. Oh, and remember that top dev talent costs more, so odds are that even low-end dev shops will end up paying a lot more for their apps, because you just can’t expect what has been traditional mainstream dev resources to be real productive in such a dynamic environment.

That’s not a slam on mainstream dev resources btw – that’s just reality. Most business developers much prefer to learn a toolset and platform and ply those skills for many years. They prefer to focus on the business problems more than on platform problems. As a business software manager I do want a coding cowboy or two, but I want the majority of my dev team to focus on the business more than on the technology. At the moment though, HTML5 doesn’t afford that option because the platform is too dynamic and volatile – so it is pretty unrealistic to think that mainstream dev resources will be nearly as productive as they were in .NET or Java or VB or C++/MFC.

All that said, the HTML5 platform is maturing. Dev tools (including from Microsoft) are improving rapidly. There’s the possibility that a subset of the myriad open source libraries will become a de facto standard for the platform as a whole. The next version of JavaScript looks like it will get some important language features for modern enterprise app dev. In other words, I really believe that if the enterprise app dev world does shift its focus to HTML 5 that the platform will stabilize over a few short years.

And in a sense Microsoft is “subsidizing” our move to HTML5 through the WinRT deployment tax. The money you would spend to deploy your WinRT business apps can be viewed as a type of savings you can apply to offset the increased cost of building and maintaining your HTML5 apps.

I strongly doubt that offset is enough to actually cover the increased costs of HTML5, at least in the short term. But again, if we all move to HTML5 I think the platform will stabilize over a few years, and as a result the costs of app dev and maintenance will go down over that time as well.

If you stop and think about this for just a second, it is pretty clear that this is a horrific outcome for Microsoft. To think that they had subsidized their entire “Microsoft developer community” to move to a cross-platform technology that eliminates the need for the Microsoft Windows client would be incredibly disheartening.

And this is why I think that, at some point in here, someone in a leadership position at Microsoft will realize the mistake they are making, and they’ll fix the WinRT licensing/deployment story so WinRT is at least as attractive for business apps as WPF+ClickOnce or HTML5.

Or they won’t come to that realization. In which case I strongly suspect Windows will become “just another BYOD OS” alongside iOS, Android, and ChromeBook. In that future the client device is a pure commodity play, because all devices will run all apps. The only way people will choose one device over another is by price and cosmetics – much like we choose automobiles today.

All automobiles do the same thing: get us from point A to point B. But we choose various brands for cosmetic reasons, or for price, or for status.

The thing is, it is hard to predict what such a fundamental change would do to Microsoft, Apple, or Google. Odds are it wouldn’t be ideal for Microsoft or Apple, because their offerings have higher costs – so they’d probably end up more like BMW and Cadillac, while most of us will run cheaper-but-still-perfectly-functional ChromeBook devices (the Ford/Chevy/Toyota equivalent).

On that note I’ll leave you (dear persistent reader) with one final thought.

Business moves slowly. Most organizations are just now moving to Windows 7, and won’t consider moving to Windows 8 (or any other alternative) for 2-4 years. As a result there’s no reason for panic. Keep building WPF+ClickOnce, or start a retooling strategy to HTML5. But remember that there’s no rush. Microsoft could easily fix the WinRT deployment tax problem in the next few months and your investment in WPF/Silverlight will translate pretty nicely to WinRT. Even your retooling costs for HTML5 wouldn’t be wasted given that you can build WinRT apps with JavaScript and WinJS as well as you can with .NET/XAML.

As a Microsoft evangelist I personally hope they make WinRT an attractive business app platform. That’d be the best possible outcome imo.

But if they don’t I’m pretty sure we’ll see a migration to HTML5 (well, really HTML6) over the next few short years, and that’ll be as exhilarating as when I switched from DEC/VAX programming to Windows Smile

Sunday, February 3, 2013 1:35:58 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, January 29, 2013

Note that this is one post in a series. Make sure to read them all. This post provides an index to the set.

This is the second blog post covering the basics around deployment of business apps (LOB apps) on Microsoft’s new Windows Runtime (WinRT) platform. The first post focused on direct costs, this one focuses on different business scenarios.

In my view the deployment story for business apps targeting WinRT is not currently good. I’ll break the story into parts depending on your scenario:

  • Developer/tester
  • Large enterprise
  • Medium enterprise
  • Small business
  • Home users (employees who work from home sometimes)

Before I get into these scenarios I want to cover the use of the Microsoft Store for business app deployment.

LOB deployment via Windows Store

A Microsoft employee suggested that what I should be recommending is that people deploy their business apps through the Windows Store. So let’s think about this a little bit, because I don’t think it is real workable.

First, suppose I build a mission-critical business app in WinRT and submit it to the store. Around 8 days later (give or take a week) the app will be approved and available from the store. My users start using the app and then we discover a bug, or a critical regulatory feature change, or some other scenario where the app is useless until fixed. So we fix the app and 8 days later (give or take a week) the update is available for my users. So during that 8+ day period what happens? Do we revert to a manual process? Do we just lose money? Do we send employees home? Obviously the store is useless for any important business app deployment scenarios.

Second, I build my non-mission-critical (really unimportant) business app in WinRT and submit it to the store. The store approval process requires that Microsoft employees manually run each part of the app. So do I give them access to my live data? My staging servers? Do I set up servers just for the Microsoft certification process? How much extra code/functionality in the client app and/or server-side infrastructure is necessary to enable Microsoft’s people to test my app? And what legal recourse do I have if Microsoft accidentally leaks my proprietary data or my trade secrets? Do I get to sue Microsoft if their disgruntled tester makes off with some of my key IP and ruins my business or my reputation? Again, the store is totally unacceptable for business app deployment scenarios.

Given that backdrop, the only alternative is ‘side-loading’. This means deployment of apps directly to computers, workstations, PCs, devices – without going through the store.

My previous blog post covers the various side-loading options, but not from a business scenario perspective such as developer/tester, large enterprise, small business, etc.

Let’s look at each scenario in turn.


If you are a developer or tester the deployment story is actually quite good. In Visual Studio 2012 you can run a wizard that will create an appx package and associated ps1 (powershell) script that can be used to install your WinRT app on any Windows 8 machine (Windows RT, Windows 8, Windows 8 Pro, Windows 8 Enterprise). The app will work for a few weeks before the developer key and/or app test certificate expires – which is fine for dev/test purposes.

You can also use the remote debugging tools in Visual Studio to deploy an app to your Windows 8 machines, and you can then attach your debugger remotely. For example, you can debug your app while it is running on a Windows RT tablet – all from your primary dev workstation. Very nice!

Large enterprise

If you are part of an enterprise that meets the following constraints there’s the start of a pretty decent WinRT LOB deployment story:

  1. All your workstations run Windows 8 Enterprise
  2. All your workstations are joined to your domain
  3. You already use Microsoft System Center to manage and deploy programs to your workstations

In this case you can push a group policy to your domain-joined Win8 Enterprise workstations to enable side-loading of WinRT apps, and you can push those apps to the workstations using System Center. Obviously this requires a pretty mature IT staff, procedures, and infrastructure, but that is true of most large enterprises.

So far so good. But most large enterprises will also have Windows RT tablets, and the story is a little different for these devices because they can’t join your domain, and aren’t running Win8 Enterprise.

For non-domain devices (Windows RT, Windows 8 Pro, Windows 8 Enterprise) you need to buy a special side-loading key for each device at $30 per device. These licenses are sold in packs of 100, which is probably not a big deal for an enterprise. You must install these keys on each device – no reuse or transfer of a key is allowed. Then you can purchase an InTune add-on for SCCM and pay $4/device/month that allows you to manage and deploy apps to the non-domain devices.

My device cost calculator spreadsheet can help you figure out the cost for your organization to cover the $30 unlock keys and InTune subscription costs.

Update: More info from Microsoft indicates that if you have an EA and Software Assurance (SA) then your domain joined Windows 8 Enterprise machines come with a "companion license" allowing you to unlock one Windows RT device without the added $30 fee. Presumably you'd talk to your EA account rep to get these companion keys.

If you add all these costs, you can see that it will cost 10’s of thousands of dollars (or more) to install and update WinRT apps across your enterprise. Realistically probably 100’s of thousands of dollars. So you might ask why you’d pay all that money when you could keep using WPF and ClickOnce for no additional charge. My only answer is that in a large enterprise perhaps a few hundred thousand dollars isn’t a big deal? (yes, that was sarcasm)

Medium enterprise

If you are part of a medium enterprise the story is generally worse. In these types of business the following is probably true:

  1. You have a mix of Windows 8 Pro and Windows 8 Enterprise
  2. Not all workstations are joined to the domain
  3. You probably don’t have a full Microsoft System Center infrastructure in place

Remember that only domain-joined Windows 8 Enterprise machines can use group policy to enable side-loading. All non-domain machines require a $30 per device side-loading key to unlock this feature (again, sold in packs of 100). This is also true of Windows RT devices of course. Surprisingly, it is also true of domain-joined Windows 8 Pro machines – they still need the $30 unlock key.

So imagine you have 240 domain-joined Win8 Enterprise machines – you can unlock them for side-loading and use SCCM plus InTune for deployment. If you don’t have SCCM fully in place then you might need to use sneaker-net to deploy and update your WinRT apps by running PowerShell scripts on each device.

Then imagine you have 40 domain-joined Win8 Pro machines. For these you need to buy 100 unlock keys ($3000) and manually unlock side-loading on each machine. Again, you’ll need SCCM+InTune or sneaker-net PowerShell deployment to get the apps installed and updated over time.

Finally, imagine you have 170 Windows RT devices – most probably not owned by your company, but by employees. You’ll have to buy 200 unlock keys ($6000) and manually unlock side-loading on each device. Remember that these keys aren’t transferable, so when an employee leaves, or chooses to replace their device, you’ll lose (and often need to replace) that unlock key. Obviously this will require some sort of key management scheme (Magenic is happy to help you write a custom solution of course Smile ).

For all these machines/devices you will need SCCM+InTune, or have an IT intern or someone run around and unlock PowerShell so people can run scripts. Then perhaps you can train at least some of your users to run the PowerShell scripts from a network share to install/update the apps.

The InTune add-on for SCCM costs $4/device/month, on top of the $30/device unlock key cost. My device cost calculator spreadsheet can help you figure out the cost for your organization to cover the $30 unlock keys and InTune subscription costs.

Odds are you’ll look at this and ask why you have to spend many thousands of extra dollars to replace WPF and ClickOnce (no unlock fees, no manual processes, etc). And I can’t argue with you – I can’t see how any medium sized business would write a WinRT LOB app at this point.

Small business

If you are part of (or more likely the owner of) a small business the story is pretty much non-existent. In this case the following is probably true:

  1. You have a mix of Windows 8 and Windows 8 Pro
  2. You have no domain
  3. You have no Microsoft System Center
  4. You have no IT staff beyond the “consultant” you bring in a couple times a year to fix network or printer problems

First off, the Windows 8 edition of Windows 8 can not do side-loading so it is impossible to deploy business apps on those machines. Microsoft tells me that you should have bought Win8 Pro in the first place, and that it is technically illegal to use Windows 8 for non-personal use. So you’ll need to upgrade those machines to Windows 8 Pro.

Next, you’ll need to buy the $30 unlock keys in packs of 100 for your Win8 Pro machines. You probably have around 20 computers, so that’s $3000 – more like $150 per machine than $30, but at least you have enough keys to accommodate future growth? And of course you’ll need to manually install the side-loading keys, unlock PowerShell, and use sneaker-net to install/update your WinRT apps.

The same is true for the handful of Windows RT tablets you or your employees are using. That’s another $3000 to get 100 unlock keys. You probably only have 8 such devices, so that’s a mere $375 per device. Again, the whole manual unlock, install, update process must be handled.

As a result, I can’t see where any small business would ever consider building a WinRT business app. It is way cheaper to keep building apps in WPF or PHP or whatever you are using today.

Employees working from home

The final scenario is cross-cutting, in that large, medium, and small businesses all have employees who occasionally (or frequently) work from home using their own personal computers.

Most of these personal home computers are retail purchases, and so run Windows 8. Not Pro or Enterprise. As a result they can not side-load apps and therefore can’t run WinRT business apps at all.

One interpretation of this move is that Microsoft has decided that we all work too much, and they are helping us achieve a better work-life balance by making it unrealistic to work from home.

Another interpretation is that they want employers to spring for the upgrade fees (plus the $30 per device) to get all home computers running Windows 8 Pro and unlocked for side-loading. It is a great way to potentially double the licensing revenue of Windows on a per-employee basis I suppose.

Or perhaps the thought is that nobody buys home computers anymore, and that we all bring our work laptops home with us to work at home. I suppose this is pretty valid, given that a lot of people have quit purchasing home PCs because they have Macs or iPads and Xboxes for gaming?

Yet another theory is that Microsoft wants all businesses to set up a HyperV server farm so home users can RDP into virtual Windows 8 Enterprise machines to do their work from home.

Personally none of these make much sense to me.

In any case, this is the first time in the history of Windows (going all the way back to around 1990) where am employee can honestly tell their boss that they can’t bring their work home with them because their home computer isn’t legally allowed to run the business software necessary to do work.


Right now it appears that Microsoft has worked very hard to devise a licensing and deployment scheme for WinRT apps designed specifically to discourage the creation of any WinRT business apps. Whether this is intentional or accidental I can’t say, but it is surely the case that no responsible business or IT manager could look at these scenarios and think that a move to WinRT for business app development makes sense at this time.

Hopefully Microsoft examines their current scheme and recognizes the severe disincentive they’ve created for WinRT development, otherwise I see a very long and bright future for WPF, ASP.NET, and PHP.

Tuesday, January 29, 2013 10:57:03 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, January 23, 2013

This is a good type of exercise - light-hearted demonstrations of the (usually) subconscious gender bias that occurs in our industry.

Wednesday, January 23, 2013 9:40:33 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, January 18, 2013

Note that this is one post in a series. Make sure to read them all. This post provides an index to the set.

I’ve been doing a lot of research around the possibility of building business apps for Windows 8 (WinRT) – focusing a lot on deployment.

The short story with deployment is summarized in this table:

  On Domain Not on domain
Windows RT n/a w/ key
Windows 8 n/a n/a
Windows 8 Pro w/ key w/ key
Windows 8 Ent yes w/ key

The “yes” designation means you can deploy to these devices at no additional cost for licensing. You will still need to figure out how to actually push the apps to the Windows 8 Enterprise computers. The options are the same as what follows where I discuss the “w/ key” designation.

The “w/ key” designation means you need to buy a $30 side-loading product activation key that is per device, and which is non-transferable. So to side-load apps on your Surface RT (for example) you need to buy a $30 key. These keys come in packs of 100, so the minimum price is $3000.

Also, you need a way to actually deploy your app. Your options include:

  • Sneaker-net with a USB key
  • Run a PowerShell script from a network share
  • Deploy via System Center (assuming you have this level of IT infrastructure)
  • Deploy via InTune, Microsoft’s cloud service, where they even provide you with a ‘corporate marketplace’

Of the four, I suspect most organizations will laugh at sneaker-net and having their users run ps1 scripts, leaving the last two options. I also suspect a lot of orgs can’t use System Center, at least when deploying to BYOD and home user devices. Beyond which, if you use System Center and want a corporate marketplace you’ll have to write that yourself. At normal consulting costs I suspect that’ll cost between $50,000 and $100,000 to build and get deployed in your organization.

Update: There is an InTune add-in for System Center. That add-in allows the use of the corporate marketplace WinRT app, and it costs $4 per device per month (plus the cost of SCCM of course).

So this leaves InTune as a primary option. InTune costs $6 per device per month.

Update: There is a more comprehensive $11 per device per month InTune subscription as well.

Let’s assume that your organization has 100 Windows RT or Windows 8 Pro devices, so you buy $3000 worth of side-loading keys. And let’s assume you use InTune. Finally let’s assume your devices have a 3 year life – which is pretty typical for corporate devices where you buy a service agreement from Lenovo or Dell or another vendor.

These 100 devices will cost $3000 for keys, plus $6 per device per month. This means that your org with 100 devices will pay around $23,000 extra to deploy a WinRT app just for this licensing.


Money you won’t pay if you use WPF or web technologies to build the app. As a result, you have to ask yourself if there’s an additional $23k of value provided by WinRT that you can’t get via WPF or a browser-based solution, otherwise targeting WinRT makes no sense.

Does anyone have other insight into the costing? Any holes in my logic that makes this sound more sane?

I’ve put the calculator spreadsheet on my SkyDrive for those who care to play around with it.

Friday, January 18, 2013 3:30:31 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, January 16, 2013

The OneNote app for WinRT (Windows 8 native) is quite nice. And it makes it smooth and easy to interact with notebooks stored on SkyDrive.

What it doesn’t make easy is to open a notebook stored on a SharePoint site. Today I finally figured out how to open a SharePoint-hosted OneNote notebook in the WinRT version.

Put the OneNote notebook file(s) into a SharePoint sub-folder in a shared document library. The name of the sub-folder matters, because this is the name that will appear for the notebook in OneNote.

Create a string URL like this (using NotePad or something like that):


Then open the WinRT version of IE and attempt to navigate to that URL. This will open the WinRT version of OneNote and you’ll probably be prompted for your domain credentials. Sign in and let OneNote find and open the notebook file(s) from that folder.

You’ll now see that folder name (“MyNoteBookFolder” in my example) as a notebook on the far left-hand side of the screen.

This could be a whole lot smoother if the OneNote app actually integrated with SharePoint, but it is a decent workaround for now.

Wednesday, January 16, 2013 6:12:19 PM (Central Standard Time, UTC-06:00)  #    Disclaimer