The .NET Stacks #35: 🔑 Nothing is certain but death and expiring certificates

This week, we talk about NuGet, Razor improvements, and more.

Dave Brock
Dave Brock

Welcome to another week, everybody. I’ve been getting some complaints; I haven’t had a bad joke in a while. I know it’d be a nice shot in the arm, but now’s not the time to be humerus.

We’re covering a lot of little things this week, so let’s get started.

This week, the .NET team announced improvements to the new Razor editor in Visual Studio (obviously in response to my complaints last week).

Six months ago, the team announced a preview of an experimental Razor editor based on a common Razor language server. (We talked about it in Issue #9, if you want all the specifics.) It’s now available in the latest Visual Studio preview (16.9 version 3).

The new Razor editor allows the team to enable C# code actions more easily—with this update, Razor can help you discover using statements and null checks. This also extends to Blazor. Check out the blog post for details (and you can fill out a survey about syntax coloring.)

The NuGet team needed some #HugOps this week as they dealt with an expired certificate that temporarily broke .NET 5 projects running on Debian Linux.

Here’s what the NuGet team had to say:

This is because of an issue reported in the ca-certificates package in which the root CA being used are not trusted and must be installed manually due to Symantec Issues. Debian removed the impacted Symantec certificate from their ca-certificates package in buster (Debian 10) impacting all user … The Debian patch was too broad in removing the certificate for all uses and created the error messages seen today.

For some good news, the NuGet website has a new Open in FuGet Package Explorer link that allows you to explore packages with FuGet.

This week, I wrote about Signed HTTP Exchanges. In our interview with Blazor creator Steve Sanderson, he mentioned it as a way to potentially help speed up runtime loading for Blazor WebAssembly applications by using it as a type of cross-site CDN cache.

Here’s what he told us:

It’s conceivable that new web platform features like Signed HTTP Exchanges could let us smartly pre-load the .NET WebAssembly runtime in a browser in the background (directly from some Microsoft CDN) while you’re visiting a Blazor WebAssembly site, so that it’s instantly available at zero download size when you go to other Blazor WebAssembly sites. Signed HTTP Exchanges allow for a modern equivalent to the older idea of a cross-site CDN cache. We don’t have a definite plan about that yet as not all browsers have added support for it.

It isn’t a sure thing because the technology is still quite new, but it’s a promising idea to overcome the largest drawback of using Blazor WebAssembly.

I’ve written about prerendering Blazor WebAssembly apps. It’s a little weird, as you give up the ability to host your app as static files. Why not host over Blazor Server, then?

This week, Andrew Lock wrote about a creative approach where you can prerender an app to static files without a host app. It does have tradeoffs—you need to define routes beforehand and it doesn’t work well if you’re working with dynamic data—but it’s worth checking out if it fits your use case.

At the Entity Framework community standup this week, they discussed the MSBuild.Sdk.SqlProj project with Jonathan Mezach. Already sitting at 42k downloads from GitHub, it’s an SDK that produces .dacpac files from SQL scripts that can be deployed using SqlPackage.exe or dotnet publish. It’s like SQL Server Data Tools but built with the latest tooling.

You can check out Jonathan’s announcement on his blog to understand how it all works and his motivations for building it.

🌎 Last week in the .NET world

🔥 The Top 3

📢 Announcements

📅 Community and events

🌎 Web development

🥅 The .NET platform

⛅ The cloud

📔 Languages

🔧 Tools

📱 Xamarin

🏗 Design, testing, and best practices

🎤 Podcasts

🎥 Videos

.NET Stacks