.NET Framework Soup

As a developer, I absolutely love the .NET Framework – even if there are some issues and concerns with versioning that occasionally drive me nuts. But from a SysAdmin perspective, there are some major issues with versioning that need to be addressed, and I’d argue that there are serious potential problems with .NET Framework distribution as well.

Detecting Currently Installed Versions of the .NET Framework

As an example of how frustrating .NET Framework versioning can be for SysAdmins, take the following post on StackOverflow about how to detect what .NET Framwork versions and service packs are installed. On the one hand, that’s such a great – and detailed – answer about how to go about determining the answer to this question that I’ve bookmarked it for future reference. On the other hand, it’s kind of a shame that this question requires such an insanely involved answer. Looking at the registry isn’t the hardest thing ever, but if you pay attention to the defined answer and look at all of the updates and ‘exceptions,’ you’ll see that registry locations and details change and fluctuate from one OS to another, and from one version of the Framework (or ‘Service Pack’) to another – to the point where trying to determine exactly which version(s) of the Framework might be on a given server are going to be not quite rocket-science for SysAdmins, but definitely way more work and effort than should really be required.

And, if it sounds like I’m maybe making a mountain out of a molehill because versioning concerns aren’t that big of a deal, consider two scenarios that highlight how critical getting this ‘stuff right’ can be. In the first scenario, imagine developers have created an application of service that requires .NET Framework 4.5 and need it deployed to some app servers that have been successfully handling .NET applications for the past few years. Admins who need to deploy these apps will want to ensure that .NET Framework 4.5 is installed – instead of .NET Framework 4.0 – but the reality is that these two versions of the Framework look identical if you’re just looking at “Installed Programs” or something similar – so figuring out what version of the Framework is actually installed would then require jumping through the hoops outlined in the Stack Overflow question listed above.  Likewise, speaking of Stack Overflow, assume developers are made aware of the critical bug in .NET Framework 4.6 that causes incorrect parameters to be passed to methods when running production workloads, and further assume that they either want to turn off RyuJIT or have their Admins do this out in production.

To figure out which boxes in their environment are potentially compromised, they’ll have to go through and determine the exact version of the .NET Framework per potentially impacted server. Again, not exactly rocket science, but since there are so many potentially different ways to determine which version of the .NET Framework is installed (depending upon OS, etc.), this task ends up being much more complicated than it really should be. (Moreover, good luck figuring out 4.6 details – as they’re not (yet?) added to that Stack Overflow answer.)

The .NET Framework as a Potential for Malware

Another potential concern with the .NET Framework is that in this age of malware (or ‘bundle-ware’ – i.e., malware with lawyers), I think it’s possible to start seeing the .NET Framework used as a payload for bundle-ware. In fact, while I haven’t bothered to see if some “enterprising” organization is actually bundling the .NET Framework with “helpful solutions and applications” yet, I do know that .NET Framework downloads are already a huge potential vector for “swindle-ware” or “confuse-ware” installations of all sorts of crap-ware.

As a case in point, a few weeks ago I had just stood up a new application server in order to offload some apps for scalability purposes. This meant I needed to “match” the version of the .NET Framework installed on the existing server on to the new “scale out” server – so (after figuring out which EXACT version I had installed on the primary server) I went ahead and Googled for “.NET 4.0.30319” hoping against hope I’d find a semi-decent link to somewhere within the bowels of Microsoft.com to a download of this specific version of the Framework. Interestingly enough, on Google, the link I had hoped for didn’t show up in the top 5 or so results. Instead, I ended up seeing some links to questions on Microsoft’s forums sites about this version of the framework, a few other links, and two links offering to let me download the specific version of the .NET Framework I was looking for.

The first of those links, though, was on a CNET site – to which I’ve provided a screenshot:

As you can see, the actual link to the download for Microsoft .NET Framework 4 is down near the bottom of the screenshot (pretty much “below the fold” in my browser) – after all of the “tempting” other offers for things to download. Interestingly enough, nearly 1 million people have actually gone this route to download and install the .NET Framework.

The second download location was similar – a link to a site called Softonic:

Only, I couldn’t really spot anything I’d be comfortable clicking in this site – for fear of “catching something”.

Now, to be clear, I don’t see that either of these sites has “bundled” the .NET Framework via some sort of “helpful” installer that would offer to install additional malware (er, sorry – “bundle-ware” – in case any lawyers are reading along), but I don’t see it being too much of a leap to assume that something like this might crop up in the future. Likewise, there might be provisions within the redistribution license details for the .NET Framework that would prevent bundling. But, then again: even if that’s the case it’s still arguable that the .NET Framework (on both of the sites listed above) has been “logically” bundled – at least in terms of attempts to “confuse” users to download all sorts of other options when visiting the sites above. That, and the entire purpose of allowing the .NET Framework to be redistributed in the first place is so that developers can streamline the installation process of their own apps and make it easier for users to, well, have the .NET Framework “bundled” in with other applications. So, on that note, I wouldn’t be surprised to find some lawyers and crapware purveyors out there, somewhere, who try to argue a loophole around bundling in the first place.

Conclusion

When developers create applications that require the .NET Framework and then bundle the Framework with their application, this should probably remove a lot of the chances or need for people to go out and find various versions of the .NET Framework themselves. But CNET is showing that nearly 1 million people have downloaded .NET 4.0 from them – so it seems to me that there’s a potential for the .NET Framework to end up being a potential catalyst for the installation of malware. Add to that the fact that it’s way more tedious for systems administrators to figure out which version of the .NET Framework is actually installed on servers, desktops, laptops, and tablets that they’re managing, and I can start to see how SysAdmins might not be the biggest fans of the .NET Framework in general. Which is a pity – given how much developers love it.

Long term, it seems like Microsoft might want to do a bit more to make the .NET Framework a bit more approachable and loveable by SysAdmins – as a way of helping increase adoption of the Framework. Then again, a skeptical part of me is reminded that many of these problems “go away” when we’re dealing with applications hosted in Azure – so maybe Microsoft’s bigger strategy or goal is simply to “do away with” SysAdmins or at least not waste any time on making things easier for them in these regards.