Last Week in .NET – July 18, 2020

I don’t know if I’ll be making posting the newsletter to my blog a habit; but if you haven’t already signed up for Last Week in .NET (or the Podcast version for those of us who are reading disinclined), here’s what last week’s newsletter looks like:

We see you, Gilthub

Github, the eponymous source control collaboration system for Open Source Projects, owned by Microsoft, has been caught trying to sneakily continue its contracts with ICE — you know, the government agency that puts kids in cages — by getting a contract award from ICE through Dell Federal Systems.

Now all of this may be on the up-and-up; Dell sells Github enterprise to ICE as a reseller, Github gets plausible deniability, and ICE gets to use the cool kids source control system.

But it’s still morally bankrupt for Github to take this contract — for an amount, I might add, that totals $79,312.50, or roughly the same amount Microsoft should have paid Keivan for using his AppGet architectural work in their WinGet package manager solution.

Special thanks to Dave Copeland for making me aware of this. Twitter is sometimes a beautiful thing.

Github ‘offers’ to let Non-US employees do the same job for half the pay.

Microsoft’s github acquired NPM. They apprently “offered” to reduce non US employees compensation by up to 50%. to do the same job.

In the Year of our Lord 2020 it is very impressive that a company like Github, who are still reeling from their morally bankrupt decision to keep an ICE contract worth $79,000, would also stoop so low as to to get existing employees of NPM to quit by offering them half the money to do the same job.

When we call supporting ICE morally bankrupt, that is not meant to inspire you to be the villian, github. That’s an insult, meant to shame you into doing the right thing.

Vulnerabilities reported this week

Microsoft reported and released a fix for CVE-2020-1147, a .NET Core Remote Code Execution Vulnerability. If you accept XML input, this advisory affects you. If any of your API endpoints accept XML, this advisory affects you. .NET Core 2.1.19, .NET 3.1.5, and .NET 5 Preview 6 are all vulnerable. This is fixed in the latest version of .NET Core 3.1.6, and will hopefully be fixed when .NET 5 Preview 7 is released.

If you are running Visual Studio 16.4, you need to update SDK to 3.1.106; if you’re running Visual studio 2019 16.5 or later, update to SDK 3.1.302 and then curse version numbers loudly like I’m about to.

If you use Windows DNS Server, there’s another RCE vulnerability that is apparently “wormable”, but at least some infosec people seem to think it won’t turn into a big problem. This being 2020, I’m not holding my breath.

Self Contained Applications

One of the more interesting parts of .NET Core has become the “Self Contained Application” -> effectively the runtime, the application and its dependencies in one package. This is great for datacenter style deployments or cross platform console applications, or even potentially in .NET 6 with MAUI: Desktop applications. That same advantage of self-contained applications is also a disadvantage, as foretold in this note in the Announcement:

Additionally, if you’ve deployed self-contained applications targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.

Long story short: Not only do you need an update story for your organization’s release cadence, that cadence must also take into account vulnerabilities in the runtime.

.NET Core 2.1.20 has been released

Release Notes:…

Nick Craver talks Attacks on Stack Overflow.

Stack Overflow, the largest (that gets developer press and isn’t Microsoft owned) site built on ASP.NET MVC (and soon .NET Core), gets a lot of attacks against it as a “top 50” (according to Wikipedia) site on the internet. Nick Craver, their architectural lead; goes deep into the sorts of attacks that happen. This is a good watch. Watch it.

Improvements in .NET 5

This is the sort of thing I get jazzed about. The faster C# gets, the less we have to worry about using a language like Go or Rust for high performance situations. I don’t use Rust, but anyone that does will tell you within seconds of meeting you. They’re our Crossfitters.

Anyway, having an easy-to-use toolchain to write fast code is good for all of us; and really good for our economic prospects, if we’re being honest. The .NET team gets jazzed about performance too, and they’ve released another blog post detailing speed improvements in the forthcoming (now in Preview) .NET 5. .NET 5, remember, is just .NET Core in a trench coat. Microsoft is going directly from .NET Core 3 to .NET 5; because awkwardly, they already have a .NET 4. I have lots of jokes to make about Microsoft Marketing, but I’d like to be clear about this: Microsoft has 20 years of inertia around the .NET Framework, and there were problem dozens of internal corporate teams that were hoping that .NET Core would fail because their bread and butter was built on .NET. Luckily it didn’t fail, and luckily the group that said “Let’s unify the two” won. Over time .NET Core has had to make concessions to stay in the game, like CSProj over project.json; but those concessions have ultimately scored large wins for both .NET Framework and .NET Core. This is a narrow line to walk, and for all the grief I give them, Microsoft’s Marketing team is handling this with grace and aplomb.

BinaryFormatter will finally be tossed off a bridge

Hashing data is now two lines of code

Special thanks to Kevin Jones @vcsjones for making me aware of this. In likely .NET 5 Preview 8, you’ll have the ability to hash data in two lines of code!:

<code>ReadOnlySpan<byte> someData; byte[] hash = SHA256.HashData(somedata); //or Span<byte> hashBuffer = stackalloc byte[32]; int bytesWritten = SHA256.HashData(someData, hashBuffer); </code>

This is pretty and awesome. It’s pretty awesome. If you find yourself producing hashes of data; it can’t get much faster or easier than this.

Windows Community Toolkit 8.0.0 Preview2 for WinUI 3 Preview 2 has been released

Microsoft continues to streamline how it versions its products by overusing the word Preview. Anyway, this release lets developers kick the tires on the new WinUI, which is better known as “How you write Desktop Applications in .NET 5”. The only hope I have is since they’ve coalesced on ridiculous versioning schemes, they’ve also coalesced around one way to develop Desktop Applications in .NET 5. Developers who love XAML should love WinUI 3.…

ImageSharp passed 6 million downloads; and an exposure angel got their wings.

The creator of ImageSharp laments getting six million downloads on an open source project that obstensibly does not pay the bills. At this point in OSS, you either go APGL or you get to the point where you wish you had.


I had understood .NET MAUI to be a codename for .NET 6. It is not. Part of .NET 6 will be ‘MAUI’. It’s capitalized because it’s an acroynmn. I should have known, of course, as we’re programmers, and we love Acroymns. Anyway, MAUI stands for: Multi-platform App UI. Or for the rest of us: Cross Platform UIs!

YES. FINALLY. Something that will be faster than electron and have less users to boot! Seriously though, I’m pretty stoked that this is happening, though I hope Microsoft will take this time to realize that cross-platform UIs are probably best done in HTML, CSS, and JavaScript, and not XAML. Actually, scratch that, Cross platform UIs are terrible in HTML, CSS, and JavaScript, but it’s ubitquitous, and that’s what matters. It looks like there will be a few ‘AppModels’ supported: MVVM, RxUI, MVU, Blazor. If you don’t do Xamarin currently, RxUI and MVU will be new to you (and to the rest of us). RxUI is a “reactive” style of programming to support one-way updates from the model to the UI. and MVU is “Model View Update”, which I hear is cool but apparently every framework needs to create a new rendering pattern, and MVU is Elm’s gift to the rest of us. Programmers create their own blog engines, UI Frameworks write their own Rendering pattern.

PFCLotW (Pretty Fricking Cool Library of the Week)

If you’re using .NET (Whether Framework or Core), and you want to benchmark your code, you should be using Benchmark.NET. It’s called Benchmark because that’s what it does, and they slapped the .NET moniker on the end because that’s what library authors for .NET Do. Since this is .NET, their alternatives were NBenchmark, and BenchmarkSharp. I’m glad Benchmark.NET won.

Anyway, Benchmark.NET let’s you set up runs against your code; specifically against doing the same operation multiple ways. It then accurately benchmarks how fast the code is, what sort of memory usage it has, and a few other neat sundries about it.

If you’re using System.Timer(), don’t. Use Benchmark.NET instead. (This is not a sponsored ad, but I do have a thing for Console Applications that are amazing)

.NET Foundation Updates

The .NET Foundation has an open pull request for changes to their bylaws to allow for a seven day comment period before a change would take effect (or be voted on?). You can view it here.

The .NET Foundation also has interviews up with all of the candidates for election to the board.

If you aren’t already a member of the .NET Foundation and you’re reading this. You should be. Decisions are made by those who show up, and those decisions affect all of us that use .NET. Become a member of the .NET Foundation here](


On July 30th, there’s a .NET Conf focused on Microservices. This conference is for people who want to add “Microservices” to their resume. Save the date here. The .NET Conf is November 10th-12th, online only. It’s the 10th year of this event. You can save the date here. If you’re not a fan of sitting through three days of online events, I’ll be live-tweeting it; In preparation, you can go ahead and block me now.

And that’s what happened Last Week in .NET

Leave a Reply