The .NET 7.0.201 release is available for download. This SDK includes the previously released .NET 7.0.3 Runtime and is in support of Visual Studio 17.5 release.  

Earlier today we finalized and published the next major release of Humanizer. This version includes many fixes and new features, many of them coming directly from the community. 

The referencesource repository contains sources from Microsoft .NET Reference Source that represent a subset of the .NET Framework. This subset contains similar functionality to the class libraries that are being developed in .NET Core. We intend to consult the referencesource repository as we develop .NET Core. It is also for the community to leverage to enable more scenarios for .NET developers. 

Visual Studio 2022 Preview 1 was released recently. While normally I hold off on talking about preview releases and other items that are going to change rapidly like .NET 6, I think it is important to know what VS2022 is all about so you know what to expect in the coming months. So in this video, we are going to see VS2022 in action, we will see what the new features are, and we will talk about what this means for VS2019. 

"We migrated Stack Overflow's ad server from .NET 4.6.2 to .NET 5.0 and we are testing it on a canary server in production. We are seeing big improvements in memory usage and in server response times. It wasn't the main goal of the migration, but definitely a nice to have" / Twitter 

In this C# 8 tutorial, I am going to introduce a selection of currently planned features which will most probably end up in the final release. All of the C# 8 features are still early in development and are likely to change. 

BenchmarkDotNet v0.10.13 has been released! This release includes:

• Mono Support for DisassemblyDiagnoser: Now you can easily get an assembly listing not only on .NET Framework/.NET Core, but also on Mono. It works on Linux, macOS, and Windows (Windows requires installed cygwin with obj and as). (See #541)
• Support ANY CoreFX and CoreCLR builds: BenchmarkDotNet allows the users to run their benchmarks against ANY CoreCLR and CoreFX builds. You can compare your local build vs MyGet feed or Debug vs Release or one version vs another. (See #651)
• C# 7.2 support (See #643)
• .NET 4.7.1 support (See 28aa94)
• Support Visual Basic project files (.vbroj) targeting .NET Core (See #626)
• DisassemblyDiagnoser now supports generic types (See #640)
• Now it's possible to benchmark both Mono and .NET Core from the same app (See #653)
• Many bug fixes (See details below) 

Blazor WebAssembly is still in preview and is not part of the .NET Core 3.0 release. 

Any experienced .NET developer knows that even though .NET applications have a garbage collector, memory leaks occur all the time. It’s not that the garbage collector has bugs, it’s just that there are ways we can (easily) cause memory leaks in a managed language.

Memory leaks are sneakily bad creatures. It’s easy to ignore them for a very long time, while they slowly destroy the application. With memory leaks, your memory consumption grows, creating GC pressure and performance problems. Finally, the program will just crash on an out-of-memory exception.

In this article, we will go over the most common reasons for memory leaks in .NET programs. All examples are in C#, but they are relevant to other languages.