Rockford Lhotka

 Tuesday, February 26, 2013

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.

h5js | Windows 8 | WinRT
Tuesday, February 26, 2013 12:21:15 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, February 25, 2013

A short time ago I decided to move the CSLA .NET project off my self-hosted Subversion server to GitHub.

I’ve used svn for years now, and really liked it a lot. But my server was getting old in the tooth, and everyone seems totally nutso about git. Apparently it not only does source control, but makes a mean gourmet meal and will eventually solve world hunger.

I want to thank Nick Schonning for helping get a lot of the GitHub stuff up and running. He just jumped in and was a great help, thank you!

My original run at moving was to just export the latest trunk from svn and add it to a blank new git repo. Sure I lost a decade’s worth of history, but my wife often tells me I just need to let go and stop being a pack rat Smile

That worked really quite well, or so I thought. The ultimate problem hadn’t really surfaced yet, and wouldn’t for a while longer. You see I was the only person using the repo, and only from a Windows dev workstation, so the (really bad) default settings for GitHub repos in terms of line termination characters didn’t cause me issues.

Here’s some technical detail on the background of the line termination issue if you are curious about stuff that shouldn’t exist in modern computing…

Then Nick kindly ran an svn2git tool and provided me with that decade’s worth of history I’d lost. Awesome! I added that to the repo and merged in the changes I’d been making. I think this is where things started to go awry, because Nick ran that tool on a Linux box, resulting in some files using LF and some using CR/LF line termination characters.

What happens to you at this point is that you change one line in a code file and GitHub thinks you’ve changed every line in that file. And often random other files too. So I’d change one file and end up with a few dozen files in my next commit. Total chaos!

Nick added a .gitattributes file, but the merge of his fork failed. People keep telling me git has flawless merges, but in my brief experience this is far from true… So I added the .gitattributes file directly. And I followed the instructions on the GitHub page dealing with line endings.

WARNING: DO NOT FOLLOW THEIR INSTRUCTIONS – THEY LEAD TO A BAD PLACE!

I was then referred to a stackoverflow post on the topic. Ultimately it appears that this thread (in and amongst the arrogance and anti-Microsoft sentiment) was what fed into the GitHub help page.

AGAIN, WARNING: DO NOT FOLLOW THEIR INSTRUCTIONS – THEY LEAD TO A BAD PLACE!

See the thing is this: I followed the instructions from these two sources. Several times. Carefully, because I kept thinking I’d overlooked some minor detail. At no point was the problem solved. In fact, it turns out that manually adding a .gitattributes file and following these instructions blocked the resolution of the problem.

Scott Hanselman discusses the issue in his blog post on the pink wall (of doom). Although this post has good info, it still left me confused – and that’s the reason I’m writing THIS blog post.

What I learned out of all this is that Scott is right: the GitHub for Windows GUI tool does fix the problem. But only if you haven’t already tried to follow the manual instructions!!!! (also Git for Windows is not the same as GitHub for Windows, and you need GitHub for Windows.

The correct overall solution is this:

Create your GitHub repo

Clone your repo to your Windows dev workstation

At this point you will not have a .gitattributes file in your repo (and this is important!!!)

Add the client-side repo to the GitHub for Windows GUI tool (if necessary)

image

Then open the repo

image

And click the Tools | Settings menu option

image

This is where I hit the problem. Because I’d already done the manual (and not successful) steps to address the problem, I already had a .gitattributes file. As a result my screen didn’t match what I’m showing you here in this blog post. You really need to see the screen I’m showing here!!

The value of this screen is that the GUI tool will perform magic of some sort. It adds a .gitattributes file as shown, and when you click the Update button it will trigger an update to all the files in your repo.

Commit those updates to fix all the line endings for all your files

Then push the commit to GitHub

From what I can determine this has solved the issue. So after wasting several hours farting around with cryptic command line tools, the solution was to let a tool do magic for a couple minutes. If only I’d known to delete the .gitattributes file earlier (or to have never manually created it) I’d have been infinitely happier.

In summary, git does seem pretty cool. But it clearly is no more of a silver bullet or super-solution than anything else in our industry. It is a decent tool, but I suggest taking all the hype about git with a shaker of salt.

git
Monday, February 25, 2013 8:23:58 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, February 20, 2013

First: CSLA .NET has moved to GitHub and has a new home page: www.cslanet.com

Second, the most recent beta version 4.5.12, is now available for download and through nuget. There are a couple bug fixes, and some server-side data portal enhancements to better support the use of IoC containers for creating business objects when using the encapsulated data portal model.

In summary, you can create an implementation of Csla.Server.IDataPortalInterceptor where you can implement code that runs at the very start and very end of every single data portal call. Then you can create an implementation of Csla.Server.IDataPortalActivator where you can assume responsibility for creating an instance of the requested business type, and for initializing the object instance (thus supporting property injection).

Along with this, the data portal now allows you to use interfaces instead of concrete types (assuming you've supplied an IDataPortalActivator of course):

var obj = Csla.DataPortal.FetchAsync<IPersonEdit>();

In this example, the 'obj' reference might be any type that implements IPersonEdit, and the actual concrete type is determined by your IDataPortalActivator implementation. The default implementation is to create an instance of the supplied type, so the supplied type must be a concrete type. As a result, no existing code is affected by this change.

Wednesday, February 20, 2013 5:30:19 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 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
Interface control
Business
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.

WTF!?!

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.

Developer/tester

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.

Summary

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.

http://www.newstatesman.com/sci-tech/2013/01/roll-first-annual-objectify-man-tech-day

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