The Misadventures of Quinxy truths, lies, and everything in between!


Microsoft Leaves .Net 3.5 (and earlier) support out of Windows 8?!?!

In a moment of anything but wisdom Microsoft has decided to leave earlier versions of the .Net (dotnet) Framework out of the Windows 8 install, including only 4 and 4.5. The reason they give for this peculiar decision is their desire to have a smaller OS install footprint. While less disk space lost to an OS install is a very noble goal, I can think of few things worse to leave out. Any user with Windows 8 who subsequently downloads and wants to use an application written against the 3.5 or earlier .Net runtimes will be forced to install (over the 'net) a reboot-required multi-hundred megabyte installer (supporting .Net 3.5, 3.0, and 2.0). Few things deter a potential user of your software more than a lengthy download and a forced reboot.

Adding insult to injury is that I am quite sure their smaller OS footprint goal is little more than an attempt to defend against one of Apple's (and others) easy anti-Windows attacks. Unless Microsoft has radically altered the way they handle Windows Updates, their Driver Store, WinSXS, temporary files, etc. then whatever savings they claim at initial install will be gone in a few months; the Windows directory of my 1.5 year old computer is a whopping 37 GB.

Why couldn't Microsoft leave out MS Paint, MS Write, Solitaire, audio recorder, Pinball, or hell, even Internet Explorer, and include the full range of .Net support? Now us poor developers are going to need to once again need to distribute versions of our software targeting multiple runtimes just to ensure most users don't have to do the absurd .Net installs.

^ Quinxy


.Net (dotnet) Install Base Statistics – Picking Your Framework Version

When building C# applications in Microsoft's Visual Studio 2011 you must make a choice, which .Net framework do you target?  As a developer we'd all love to target the latest framework which has all the latest features, but you don't want to lose out on a huge percentage of potential users who balk at the torturous Microsoft .Net installation.  If a user doesn't have the needed version of the .Net framework they'll be forced to download an additional 25+ MB file, forced to wait as that framework is installed, then forced to close all their applications and reboot their computer.  With past applications we've deployed we've seen as many as 30% of people abandon our software's installation in order to avoid the .Net installation.  Picking your framework is, therefore, important.  Target the wrong one and you'll lose more users than you need.

It has been difficult to determine just want version to target as Microsoft hardly wants to publish the anemic numbers themselves, and no one else seems much interested in sharing their own.  We included a .Net version checker in some of the software we distribute to find the truth ourselves... and here it is.  These numbers represent the users coming to, so other sites with different audiences would likely see different numbers, but I suspect they'd not be too far off.

.Net Version Percentage of Computers Scanned
pre 1.1 (or none) 21.6%
1.1 no service pack 27.2%
1.1 SP 1 24.6%
2.0 no service pack 74.2%
2.0 SP 1 1.7%
2.0 SP 2 62.7%
3.0 no service pack 62.4%
3.0 SP 1 1.0%
3.0 SP 2 61.5%
3.5 no service pack 61.6%
3.5 SP 1 61.3%
4.0 client install 28.3%
4.0 full install 5.6%

Unless you can be sure your users will tolerate the painful .Net framework installations this data clearly shows you only have two real choices, either target 2.0 and seriously inconvenience 25% of people or choose 3.5 and seriously inconvenience 38%.  Neither are good options, but they are what Microsoft leaves you with.

One alternative which we've flirted with in the past is to bypass the horrific .Net installation requirement was using Xenocode's Postbuild software to create a distributable that was free of the .Net installation because the exe built with Postbuild included the necessary .Net components inside a virtual machine wrapper.  It worked beautifully, but made our tiny 150 KB executable into a self-compressed 25 MB executable.  Still, in this day and age of broadband Internet one could hardly argue it wasn't a far better user experience.  Xenocode Postbuild has since morphed into a more encompassing idea with a slightly different built utility called Spoon Studio which we are currently testing; we've found similar results so far.

Virtualization was done with Spoon Studio and bundled the .Net 3.5 Client Profile.

Compression Method Size
Raw, Spoon Not Used 150 KB
Streamable / No Compression 50 MB
Not-Streamable / Compressed by Spoon 18 MB
Not-Streamable / Compressed as RAR SFX 15 MB
Not-Streamable / Compressed as 7-Zip SFX 13.5 MB

We will likely do what we've done before and deploy a tiny installer which bundles only in only the raw .Net dependent executable and then for the 40% of people we see don't have the right .Net version we'll automatically fetch the larger monolithic exe they'll need over the net.  It's as near to an ideal situation as we can have when Microsoft insists on making .Net installation so horrible.