Rockford Lhotka

 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
 Thursday, December 20, 2012

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

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

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

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

Creating the Package

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


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

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


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

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


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


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

Unlocking PowerShell

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

Set-ExecutionPolicy unrestricted

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

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

Installing the App

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

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

The script will ask permission to run.


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

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



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


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

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

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

Thursday, December 20, 2012 12:06:59 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, December 19, 2012

This is something I use from time to time, and I thought I’d post it here so I can more easily find it next time I need the code.

This is an IDataReader implementation that reads in comma-separated value files. Probably incomplete, but it works well in the scenarios where I’ve needed it.

using System;
using System.Data;
using System.IO;

namespace Csla.Data
  public class CsvDataReader : IDataReader, IDisposable
    private StreamReader _file;
    private string[] _headers;
    private string[] _line;

    public CsvDataReader(string filePath)
      _file = File.OpenText(filePath);
      _headers = _line;

    public void Close()
      _file = null;

    public int Depth
      get { throw new NotImplementedException(); }

    public DataTable GetSchemaTable()
      throw new NotImplementedException();

    public bool IsClosed
      get { return _file == null; }

    public bool NextResult()
      return false;

    public bool Read()
      var result = !_file.EndOfStream;
      if (result)
        _line = _file.ReadLine().Split(',');
      return result;

    public int RecordsAffected
      get { throw new NotImplementedException(); }

    public void Dispose()
      if (_file != null)
        _file = null;

    public int FieldCount
      get { return _headers.Length; }

    public bool GetBoolean(int i)
      return Boolean.Parse(_line[i]);

    public byte GetByte(int i)
      return Byte.Parse(_line[i]);

    public long GetBytes(int i, long fieldOffset, byte[] buffer, int bufferoffset, int length)
      throw new NotImplementedException();

    public char GetChar(int i)
      return Char.Parse(_line[i]);

    public long GetChars(int i, long fieldoffset, char[] buffer, int bufferoffset, int length)
      throw new NotImplementedException();

    public IDataReader GetData(int i)
      throw new NotImplementedException();

    public string GetDataTypeName(int i)
      throw new NotImplementedException();

    public DateTime GetDateTime(int i)
      return DateTime.Parse(_line[i]);

    public decimal GetDecimal(int i)
      return Decimal.Parse(_line[i]);

    public double GetDouble(int i)
      return Double.Parse(_line[i]);

    public Type GetFieldType(int i)
      throw new NotImplementedException();

    public float GetFloat(int i)
      return float.Parse(_line[i]);

    public Guid GetGuid(int i)
      return Guid.Parse(_line[i]);

    public short GetInt16(int i)
      return Int16.Parse(_line[i]);

    public int GetInt32(int i)
      return Int32.Parse(_line[i]);

    public long GetInt64(int i)
      return Int64.Parse(_line[i]);

    public string GetName(int i)
      return _headers[i];

    public int GetOrdinal(string name)
      int result = -1;
      for (int i = 0; i < _headers.Length; i++)
        if (_headers[i] == name)
          result = i;
      return result;

    public string GetString(int i)
      return _line[i];

    public object GetValue(int i)
      return _line[i];

    public int GetValues(object[] values)
      throw new NotImplementedException();

    public bool IsDBNull(int i)
      return string.IsNullOrWhiteSpace(_line[i]);

    public object this[string name]
      get { return _line[GetOrdinal(name)]; }

    public object this[int i]
      get { return GetValue(i); }
Wednesday, December 19, 2012 10:00:22 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, December 7, 2012

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

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

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

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

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

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

Obviously there’s a fine line here.

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

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

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

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

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

Friday, December 7, 2012 11:23:33 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Sunday, November 25, 2012

There’ve been a variety of articles and blog posts about the Microsoft Surface, with people expressing pleasure or disappointment as they’ve played with the device.

I thought I’d share my experience with the Surface RT, having now used it for a few weeks.

First though, it is important to understand that I’ve been running Windows 8 full time for months on my laptop and on my Intel-based tablet. When I started running Win8 I consciously chose not to run any of those apps to make Win8 act more like Win7. I never tried to make WinXP look like Win98, or Win7 look like WinXP, so why would I try to make Win8 look like an obsolete OS? Embrace the new, that’s my view!

Also, it is important to understand that I had an iPad at the beginning. That was comparable to the Surface, in that there were basically no iPad apps – just the ability to run iPhone apps on the iPad, which was a really lame experience. So my iPad experience was that the device was reasonable for web browsing and limited entertainment, but had no practical value at all – because it had no Office, or Lync, or other useful apps. I fully appreciate that now, years later, the iPad does have useful apps and can be useful for something other than entertainment and games. But it is important (I think) to appreciate that my iPad experience is directly analogous to my Surface experience – I used both at the start of their existence. (as an aside, I gave my iPad to my wife, because I saw no reason to lug around another entertainment device as I travel)

Given that background, I’ll start by saying that I use my Surface RT every day. A lot. And I like it. I do also find it frustrating at times.

I find it useful for web browsing, entertainment, and productivity.

From an entertainment perspective, it has a bunch of games, it has Netflix and Hulu and Xbox music/video. And it browses the web, which is also entertainment. The only thing I’m missing is Amazon streaming video, which is Amazon’s loss in terms of competing with Netflix/Hulu, so they better get a WinRT app out ASAP or they’ll probably lose me as a Prime customer. Not a customer totally though, because I’m a Kindle addict and occasionally use the Kindle app on the Surface. I still prefer my Kindle Touch though, because eInk is way superior to the shiny-screened Surface or iPad.

From a productive web browsing perspective I find IE10 to be just fine. I am able to use all the sites I need for work, including, SharePoint, yammer, skydrive, Google drive, etc. The browsing experience is generally fast enough to be pleasant, with the exception of yammer’s text editing where they run really intensive js scripts for every keystroke. I haven’t tried their site on the iPad, but I suspect it is laggy there too due to this intense use of scripting.

In terms of pure productivity, the Surface is pretty good. I use Word and Excel pretty much daily, reading and editing documents from SkyDrive and collaborating with colleagues on projects. Lync and Skype both work well for telecom (which is important because Magenic’s entire “phone system” is Lync). I’ve used PowerPoint a little, but generally find editing presentations to be easier when using a full-size keyboard/mouse and my big monitors on my main computer. Using Word and Excel on the Surface (with its keyboard) is perfectly fine though, and I use those apps a lot.

I also use OneNote a lot. Much of my life exists in Outlook and OneNote. As a result the Surface provides me with access to much of my life through OneNote. I use the WinRT app, and I’m not sure I’ve even run the OneNote app from Office on my Surface.

The apps I have running on every one of my Win8 devices include:

  • Office
  • OneNote for WinRT
  • Tweetro
  • Skype
  • Lync
  • Feed Reader
  • Remote desktop
  • News/Weather/Stocks
  • Xbox Music/Video
  • Netflix
  • Hulu
  • Youtube player
  • Khan Academy
  • Calc
  • File Manager
  • TED Talks HD
  • All My Storage (at least until there’s a real DropBox app)
  • Bing

What is missing, and this is a big hole for me, is Outlook. The email client in Win8 is pretty lame. Perhaps adequate for casual email use, but not remotely adequate for productivity users. It has poor calendar integration, no Lync integration, no flagging of emails. It just isn’t even close to Outlook. Similarly the Calendar app on Win8 is lame. Well, it is worse than lame – it is really hard to read or use. Again, it also has no Lync integration and is largely useless for ‘real work’. Although I do use both the email and calendar apps, the experience is frustrating at best.

Similarly, the WinRT Lync app doesn’t compare to the real Lync client on an Intel machine. It is a limited subset of functionality. Fine for making and receiving calls, but extremely poor for collaboration scenarios where you need to share your screen.

I do wish that the SkyDrive app supported interaction with shared folders. When I’m collaborating with people on projects we often use shared folders in SkyDrive, but the SkyDrive app for WinRT doesn’t understand that concept, forcing me to drop into the browser to access those documents.

Finally, there is a general lack of apps in the Microsoft Store. This is directly comparable to my iPad experience (remember, at the start of the iPad’s existence) – with the notable exception that Surface comes with Office, so the single biggest set of apps I need are available right now on the Surface, unlike with the iPad (even today there’s no actual Office there, nor the amazingly smooth integration with SkyDrive).

For me, the big missing apps in WinRT include:

  • Outlook
  • Full featured Lync
  • DropBox
  • Yammer
  • TripIt
  • Amazon streaming video
  • Quicken

In short, at this comparable point in time with the iPad I gave the device away because it was just more weight to carry for little value. But I find my Surface RT continually valuable and have no plan to stop using it. The fact that it has Office and that it smoothly integrates into the SkyDrive ecosystem along with my desktop, laptop, and phone (WP8) makes it incredibly useful. I move seamlessly between my various devices, able to view and edit my documents regardless of where I am or what size screen I’m using.

So yes, I really like my Surface RT. There’s some frustration, but not nearly as much as when I was a month into using the iPad.

I have high hopes for Windows 8, WinRT, and Surface (and similar devices).

Sunday, November 25, 2012 11:48:20 AM (Central Standard Time, UTC-06:00)  #    Disclaimer