The .NET Stacks #47: 🧨 Now with 32 more bits

#dotnet #csharp #azure

NOTE: This is the web version of my weekly newsletter, which was released on April 26, 2021. To get the issues right away, subscribe at dotnetstacks.com or at the bottom of this post.

Happy Monday! Here’s what we’re talking about this week:

One big thing: Visual Studio 2022 to be 64-bit
The little thing: API updates coming to Preview 4, memory dump tooling, dotnet monitor updates
Last week in the .NET world

One big thing: Visual Studio 2022 to be 64-bit

Last week, I provided a tooling update. Figuring the next major updates would occur around Build, it was a good time to get up to speed. I pushed the newsletter, started my workday, then an hour later, Amanda Silver wrote a post about Visual Studio 2022. Oops.

The biggest news: Visual Studio 2022 will be 64-bit and is no longer chained to limited memory (4 gigs or so) in the main devenv.exe process. If you look at Silver’s post, she has a video of a 64-bit Visual Studio app working easily with 1600 projects and 300k files. Finally.

With interest dating back in 2011, the Visual Studio team responded in 2016, saying that “at this time we don’t believe the returns merit the investment and resultant complexity.” Times have changed—hardware capabilities have improved, and VS is no longer the only .NET IDE option—and it’s now worth it.

For example, if you look at the issue in the Developer Community, a few comments echo what Microsoft has heard for a few years now:

This year my company(size 15k+) started to provide RAIDER to employees and plans to cancel our Enterprise VS subscriptions as VS is highly unproductive because of memory limitations of 32 bit application.

Lately I’m mainly using Rider. It does about 80% of what VS does, but it does that 80% without worrying about running out of ram.

To be clear, as David Ramel notes, Visual Studio has been available in a 64-bit edition to create 64-bit apps on 64-bit machines, but the application itself has previously been a 32-bit app. JetBrains cheekily welcomed Visual Studio to the 64-bit club, but this also means ReSharper will have more room to breathe. When the time comes, you’ll need to grab 64-bit versions of your favorite extensions as well.

Of course, 64-bit support isn’t the only thing coming to Visual Studio 2022. VS 2022 promises a better UI interface, enhanced diagnostics and debugging, productivity updates, improved code search, and more. The first preview will ship this summer, with UI refinements and accessibility improvements. In the meantime, you can check out the most requested features from the community.

The little things: API updates coming to Preview 4, async analyzers, dotnet monitor updates

A couple weeks ago, we talked about the FeatherHttp project, a lightweight, scalable way of writing APIs without the typical overhead that comes with .NET APIs today.

Here’s what I said about it:

Fowler says the repo has three key goals: to be built on the same primitives on .NET Core, to be optimized to build HTTP APIs quickly, and having the ability to take advantage of existing .NET Core middleware and frameworks. According to a GitHub comment, the solution uses 90% of ASP.NET Core and changes the Startup pattern to be more lightweight.

That functionality will start rolling out in .NET 6 Preview 4 in a few weeks. (Along with AOT support, Preview 4 promises to be a satisfying update.)

David Fowler tweeted about it and the discussion was spicy.

I’m personally excited to give this a spin. If it isn’t your jam, it doesn’t have to be—it isn’t a breaking change, and you can always use your current solution. But as APIs evolve with microservices, much of the core logic is done outside of the endpoints anyway, so you may find you don’t need the complexity and overhead with writing APIs in MVC.

Mark Downie and his team have been doing some great work with managed memory dump analyzers. If you think that’s too low-level, reconsider—when logging and local debugging fail you (or issues aren’t reproducible easily), memory dump analysis can be your friend. It isn’t always easy to work with memory dumps, though. To help folks new to dump debugging, Microsoft has developed a new .NET Diagnostics Analyzer tool to quickly identify or rule out issues.

A great use case is finding async anti-patterns, a common cause of thread starvation, which only may become prevelant when you hit high production workloads. Check out the blog post to see how it can detect some “sync-over-async” issues.

In passing, we’ve talked about the dotnet monitor tool. It allows you to access diagnostics information with a dotnet process. It’s no longer experimental: it’s now a supported tool in the .NET ecosystem. Sourabh Shirhatti wrote about that and recent updates.

Lastly, a nice tip from Khalid Abuhakmeh: