I've updated my .NET Availability and Viability With Portable Apps statistical and functional analysis with the latest info and worldwide OS stats. The news is a bit mixed for fans of .NET and .NET-based apps who like to use portable software.
While Windows XP has been end-of-lifed and most folks in many more prosperous countries won't encounter it anymore, it's still holding with over 25% of Windows installs. So, some folks will still have to deal with it on a regular basis.
Even discounting that, Microsoft's decision to disable .NET 2.0, 3.0, and 3.5 (and discontinue 1.0/1.1 entirely) on Windows 8, 8.1 and 8.1 update 1 will throw a major wrench into the lives of anyone expecting their .NET portable apps to work everywhere. On Windows 8 and up, .NET 4.5 is installed by default, which is a good thing for .NET fans. But... and there is a BIG but here... Microsoft decided that nothing below 4.0 will be supported by default unless an administrator goes in and manually enables earlier .NET versions.
As an example, this means that while your handy zipped version of KeePass 2.0 will work out of the box on Windows Vista and Windows 7, it won't work on any Windows 8 boxes unless the admin has gone in and manually enabled it after the OS was installed. (UPDATE: As noted below, I was incorrect. KeePass 2 is specifically configured to work on .NET 4/4.5 as well.) So, basically, you can forget about universal portable app support for .NET. We'll need to check and see what .NET version the app needs and whether it's installed and/or enabled on a give PC before launching still.
So, what does this mean for .NET on PortableApps.com? It means nothing changes from our original plan. The PA.c Format already includes a line to indicate which version of .NET an app needs (if it needs it). And the platform will be updated in the near future to automatically read that and check for it, either greying out or hiding apps that won't run on the current PC. As planned, we'll be officially releasing .NET-based apps, but we'll be relegating them to a separate section of the app directory that users can choose to enable or disable based on whether they want to deal with .NET uncertainties.
UPDATE - Thanks to winterblood pointing out that .NET apps can be set to support multiple runtimes. While this doesn't change the base percentage of what .NET frameworks run where (my original linked article), it does change the percentages of where a give app will run. This does open up the possibility of us including .NET apps broadly. Read my response below for more details.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
The way .NET apps run is that they try to find and use the exact version they were built on, if it isn't found on the PC it will die miserably. However .NET developers can list a set of versions in the app's configuration file that it will fall back to if the primary version wasn't found. This list of supported versions has been around since .NET 1.1, so it is both established and (I would assume) widely recognized in the .NET community.
So at least for apps that are still under active development that doesn't make it as bad as it originally sounds, because the developers can easily enough indicate that their app will run on 4.0 and 4.5 even if it was built on 2.0. So your example of KeePass 2.0 isn't correct, as long as the developers are actively maintaining the configuration file for KeePass 2.0 (which you would assume most .NET developers who have more than a passing interest in their own work would do).
The unfortunate side-effect of this is that an app may be marked as supporting 3.5, 4.0 Full and 4.5, but not 4.0 Client in its config, meaning that our detection systems may need more than just a simple "greater than 3.5" version check.
Ah, you're right. I hadn't kept up on that and had thought that a .NET 2.0 app needed the .NET 2.0 framework. KeePass 2.0 specifically is set for 2.0, 4.0 and 4.5. So, it does work on Windows 8 out of the box. I just checked it to be sure. Thanks for pointing all that out. And bad on me for not double-checking my original research and premises on a clean Windows 8 machine.
You're also right that this makes our checking for compatibility more complicated. Or we could simply require that .NET apps we package in PA.c Format support the proper range if they are 2.0, 3.0, or 3.5 apps. Specifically, they have to list 4.5 as supportedRuntime in their startup section of the configuration. That way, they'll work on Vista, 7, 8, and (hopefully) later out of the box.
We'll still need to come up with proper checks for Windows XP. Even though it's been end of lifed, it's still on about 25% of desktops around the world and still supported by Firefox, Opera, Chrome, and most major antivirus vendors.
That does still leave the issue of 4.0 and 4.5 apps, though. Those versions of .NET aren't included on Windows Vista and 7 by default. 4.5 isn't supported by Windows XP at all. So, we'll need to come up with a proper policy around all of that.
All that said, with the details of how supportedRuntime works, I think we could possibly see our way to including specific .NET 2.0/3.0/3.5 apps in our directory proper (not just the .NET branch). As long as they are configured as KeePass is, they'll work on most modern Windows machines without issue and without administrative intervention.
Sometimes, the impossible can become possible, if you're awesome!
3.5 is the default on 7, but not on a base Vista, so 3.5 apps would still require a check.
But if a config file listed either 2.0 or 3.0, plus 4.5, the app should run on every Vista/7/8 machine without checking, so we'd only have to run checks for XP in this case.
This is more/less what I was trying to get across last night. With multiple runtime dependency allowances, portability of .NET is not as much of an issue as it has been historically.
True. Unfortunately Twitter sucks for trying to convey something that takes a paragraph.
Unfortunately, this really only applies to 2 and 3. And then only if they have the proper runtime dependency configuration. Later versions still won't work on Vista/7 out of the box, making them a non-starter for inclusion in the Portable App Directory proper.
We'll need to do some clean installs of Vista and 7 to see what they get automatically updated to as well as that could factor into our decision. Unlike Windows XP, which was often pirated, Vista and up did a better job of locking out pirates, which means that they're usually hooked up to Windows Update and regularly updated. As always, the vast majority never do this manually and just do the defaults that Windows pushes down. Here's what I know:
Win XP shipped with no .NET framework
Vista shipped with .NET 3.0 (and I *think* got the 3.5 update automatically)
Win 7 shipped with .NET 3.5 (unsure what automatic ones it gets)
Win 8 shipped with .NET 4.5
Win 8.1 shipped with .NET 4.5.1
For percentages of users for each, see my chart: http://johnhaller.com/useful-stuff/dot-net-portable-apps
In the end, it may come down to having three settings for .NET apps for users. Enabled, Disabled, and Automatic. Automatic will be the default, but only show .NET apps that work out of the box on Windows Vista, 7, and 8. That way no users that don't understand .NET and its limitations will be stuck with a random app not working on a PC they plug into.
Sometimes, the impossible can become possible, if you're awesome!
I checked on a relatively clean install of Windows Vista and looked at the history as well. It seems .NET 3.5 was pushed out as an 'important' update around when it was released to Vista users. .NET 4.5, however, is a 'recommended' update, which users can select whether or not to install automatically as they install Windows. I'm unsure of the percentage of users who do vs don't do this on Vista. I think on modern Windows it's more likely due to the UI of the install.
So, it would seem we can be relatively confident of Vista having .NET 3.5 SP1. Whether or not they have .NET 4.5 depends on whether they selected to automatically install 'recommended' updates or manually chose to install .NET 4.5.
Sometimes, the impossible can become possible, if you're awesome!
Windows 7 ships with .NET 3.5 bundled in and will automatically apply updates to it. As with Vista, it depends on whether the user selected to automatically apply important and recommended updates or just important when they originally installed.
So, we can be confident of Windows 7 having .NET 3.5 SP1 installed. Whether or not they have .NET 4.5 depends on whether they selected to automatically install 'recommended' updates or manually chose to install .NET 4.5.
Sometimes, the impossible can become possible, if you're awesome!