TG: Programming: .NET Assembly Hell - System.Net.Http on Windows 2016

Home - Programming - .NET Assembly Hell - System.Net.Http on Windows 2016

The solution being deployed consisted of a plugin that customized Retail Pro, a point of sale solution, and a configurator that made it possible to manage the general configuration and the configurations for the workstations from a single point. A problem cropped up while deploying a solution across 30+ stores. Most of the stores deployed without incident, but on the stores where the server was using Windows 2016 we would get an error from the configurator's test buttons that System.Net.Http could not be loaded.

After some preliminary triage, I did a search on the web for "Windows 2016, can't load System.Net.Http", and got a LONG list of hits. Apparently this is something that was a wide spread problem starting about 8 years ago. There are two ways to fix it. The customer can upgrade Windows to a server version that isn't brain damaged, or I could update my project by digging around in the XML for web.config, the .csproj, etc., ripping out XML, adding XML, deleting all references, dancing with NuGet, etc.

In other words, I was once again, through no fault of my own, thrown back into Assembly Hell.

I want to take a moment to point out that this kind of thing NEVER happens with Delphi. I can develop better solutions, focusing more on the business logic and less on the idiosyncracies of the tools, and I can do it much faster. And when it comes time to deploy, I just have to place one EXE, and potentially some third party DLLs, to get it working. I'm not beholden to the customer's Windows version, I don't have to have the customer update any frameworks on the target machine, and I don't have to register the assemblies on each machine that's going to use the software. Every single damn machine. In a client-server situation, that can mean remoting into dozens of computers per site, and that's a serious pain in butt. When developing with Delphi, development and deployment are smooth as glass.

Just sayin'.

But Microsoft had to make things needlessly complex by forcing the use of their frameworks onto developers, and then doing a crap job of keeping those frameworks updated. Sorry, but it's true. I get that part of the purpose behind assemblies is to decrease bloat, but with terabyte drives being common, the only people that care about bloat are developers. The end customer just wants the stuff to work. If you've created a needlessly high bar to development that shouldn't exist at all, you've failed.

But failure is something to which Microsoft is accustomed. It's practically a feature of their architecture.

My second complaint is that I should NEVER have to directly tinker with the XML of .csproj, web.config, app.config, or any other module in Visual Studio. There should be wizards or GUI tools for this, something that prevents errors from being made. I've been using XML for decades, so it's not that I'm uncomfortable with XML configuration files. What I'm saying is, this is an error prone approach, and GUI tools are not only able to validate changes, but they are more informational than the XML they manage. Shame on the Visual Studio developers for being so lazy.

So anyway...

I pushed all my code changes to the repo, snapshotted the VM in case things went seriously sideways, then ran through one of the scripts I found on Stackoverflow, doing a binding redirect. Yeah, it fixed it. It also required that we re-deploy to the stores that were using Windows 2016, and because of assembly hell, that means installing on the server, then remoting into each workstation and registering the updated assemblies.

Because Microsoft.

You're welcome.