|
Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
|
You can build .NET 8.0 from the repository by cloning the release tag v8.0.124 and following the build instructions in the main README.md.
Alternatively, you can build from the sources attached to this release directly.
More information on this process can be found in the dotnet/dotnet repository.
Attached are PGP signatures for the GitHub generated tarball and zipball. You can find the public key at https://dot.net/release-key-2023
Here's a summary of what's new in ASP.NET Core in this preview release:
Log in
OnRowClick eventRelativeToCurrentUriGetUriWithHash() extension methodInvokeVoidAsync() analyzerIComponentPropertyActivatorConfigureConnection for Interactive Server componentsIHostedService support in Blazor WebAssemblyIOutputCachePolicyProviderASP.NET Core updates in .NET 11:
This is a release candidate of Windows Package Manager v1.28. If you find any bugs or problems, please help us out by filing an issue.
New feature that adds an 'edit' subcommand to the 'source' command. This can be used to set an explicit source to be implicit and vice-versa. For example, with this feature you can make the 'winget-font' source an implicit source instead of explicit source.
To use the feature, try winget source edit winget-font to set the Explicit state to the default.
The new feature enables a new option for the list command, --details. When supplied, the output is no longer a table view of the results but is instead a series of show like outputs drawing data from the installed item.
An example output for a single installed package is:
> wingetdev list Microsoft.VisualStudio.2022.Enterprise --details
Visual Studio Enterprise 2022 [Microsoft.VisualStudio.2022.Enterprise]
Version: 17.14.21 (November 2025)
Publisher: Microsoft Corporation
Local Identifier: ARP\Machine\X86\875fed29
Product Code: 875fed29
Installer Category: exe
Installed Scope: Machine
Installed Location: C:\Program Files\Microsoft Visual Studio\2022\Enterprise
Available Upgrades:
winget [17.14.23]If sixels are enabled and supported by the terminal, an icon for the installed package will be shown.
--suppress-initial-details now works with winget configure test--suppress-initial-details no longer requires --accept-configuration-agreementsFont experimental feature to accurately reflect fonts as the required setting valuelist by @JohnMcPMS in #5939Full Changelog: v1.12.470...v1.28.190
The most shameful thing I did in the workplace was lie to a colleague. It was about ten years ago, I was a fresh-faced intern, and in the rush to deliver something I’d skipped the step of testing my work in staging1. It did not work. When deployed to production, it didn’t work there either. No big deal, in general terms: the page we were working on wasn’t yet customer-facing. But my colleague asked me over his desk whether this worked when I’d tested it, and I said something like “it sure did, no idea what happened”.
I bet he forgot about it immediately. I could have just messed up the testing (for instance, by accidentally running some different code than the code I pushed), or he knew I’d probably lied, and didn’t really care. I haven’t forgotten about it. Even a decade later, I’m still ashamed to write it down.
Of course I’m not ashamed about the mistake. I was sloppy to not test my work, but I’ve cut corners since then when I felt it was necessary, and I stand by that decision. I’m ashamed about how I handled it. But even that I understand. I was a kid, trying to learn quickly and prove I belonged in tech. The last thing I wanted to do was to dwell on the way I screwed up. If I were in my colleague’s shoes now, I’d have brushed it off too2. How do I try to handle mistakes now?
The most important thing is to control your emotions. If you’re anything like me, your strongest emotional reactions at work will be reserved for the times you’ve screwed up. There are usually two countervailing emotions at play here: the desire to defend yourself, find excuses, and minimize the consequences; and the desire to confess your guilt, abase yourself, and beg for forgiveness. Both of these are traps.
Obviously making excuses for yourself (or flat-out denying the mistake, like I did) is bad. But going in the other direction and publicly beating yourself up about it is just as bad. It’s bad for a few reasons.
First, you’re effectively asking the people around you to take the time and effort to reassure you, when they should be focused on the problem. Second, you’re taking yourself out of the group of people who are focused on the problem, when often you’re the best situated to figure out what to do: since it’s your mistake, you have the most context. Third, it’s just not professional.
So what should you do? For the first little while, do nothing. Emotional reactions fade over time. Try and just ride out the initial jolt of realizing you screwed up, and the impulse to leap into action to fix it. Most of the worst reactions to screwing up happen in the immediate aftermath, so if you can simply do nothing during that period you’re already off to a good start. For me, this takes about thirty seconds. How much time you’ll need depends on you, but hopefully it’s under ten minutes. More than that and you might need to grit your teeth and work through it.
Once you’re confident you’re under control, the next step is to tell people what happened. Typically you want to tell your manager, but depending on the problem it could also be a colleague or someone else. It’s really important here to be matter-of-fact about it, or you risk falling into the “I’m so terrible, please reassure me” trap I discussed above. You often don’t even need to explicitly say “I made a mistake”, if it’s obvious from context. Just say “I deployed a change and it’s broken X feature” (or whatever the problem is).
You should do this before you’ve come up with a solution. It’s tempting to try to conceal your mistake and just quietly solve it. But for user-facing mistakes, concealment is impossible - somebody will raise a ticket eventually - and if you don’t communicate the issue, you risk someone else discovering it and independently raising it.
In the worst case, while you’re quietly working on a fix, you’ll discover that somebody else has declared an incident. Of course, you understand the problem perfectly (since you caused it), and you know that it was caused by a bad deploy and is easily fixable. But the other people on the incident call don’t know all that. They’re thinking about the worst-case scenarios, wondering if it’s database or network-related, paging in all kinds of teams, causing all kinds of hassle. All of that could have been avoided if you had reported the issue immediately.
In my experience, tech company managers will forgive mistakes3, but they won’t forgive being made to look like a fool. In particular, they won’t forgive being deprived of critical information. If they’re asked to explain the incident by their boss, and they have to flounder around because they lack the context that you had all along, that may harm your relationship with them for good. On the other hand, if you give them a clear summary of the problem right away, and they’re able to seem like they’re on top of things to their manager, you might even earn credit for the situation (despite having caused it with your initial mistake).
However, you probably won’t earn credit. This is where I diverge from the popular software engineering wisdom that incidents are always the fault of systems, never of individuals. Of course incidents are caused by the interactions of complex systems. Everything in the universe is caused by the interactions of complex systems! But one cause in that chain is often somebody screwing up4.
If you’re a manager of an engineering organization, and you want a project to succeed, you probably have a mental shortlist of the engineers in your org who can reliably lead projects5. If an engineer screws up repeatedly, they’re likely to drop off that list (or at least get an asterisk next to their name).
It doesn’t really matter if you had a good technical reason to make the mistake, or if it’s excusable. Managers don’t care about that stuff, because they simply don’t have the technical context to know if it’s true or if you’re just trying to talk your way out of it. What managers do have the context to evaluate is results, so that’s what they judge you on. That means some failures are acceptable, so long as you’ve got enough successes to balance them out.
Being a strong engineer is about finding a balance between always being right and taking risks. If you prioritize always being right, you can probably avoid making mistakes, but you won’t be able to lead projects (since that always requires taking risks). Therefore, the optimal amount of mistakes at work is not zero. Unless you’re working in a few select industries6, you should expect to make mistakes now and then, otherwise you’re likely working far too slow.
From memory, I think I had tested an earlier version of the code, but then I made some tweaks and skipped the step where I tested that it worked even with those tweaks.
↩Though I would have made a mental note (and if someone more senior had done this, I would have been a bit less forgiving).
↩Though they may not forget them. More on that later.
↩It’s probably not that comforting to replace “you screwed up by being incompetent” with “it’s not your fault, it’s the system’s fault for hiring an engineer as incompetent as you”.
↩For more on that, see How I ship projects at large tech companies.
↩The classic examples are pacemakers and the Space Shuttle (should that now be Starship/New Glenn)?
↩
Today, we are excited to announce the first preview release of .NET 11! We just shipped our first preview release, adding to some major enhancements across the .NET Runtime, SDK, libraries, C#, ASP.NET Core, Blazor, .NET MAUI, and more. Check out the full release notes linked below and get started today.
This release contains the following improvements.
Libraries
Runtime
SDK
dotnet run: Interactive Target Framework and Device Selectiondotnet test: Positional Argumentsdotnet watch: Hot Reload Reference Changes and Configurable Ports
MSBuildThis release you will find updates across the F# compiler, including parallel compilation enabled by default, faster compilation of computation expression-heavy code, new features like --disableLanguageFeature and --typecheck-only for FSI, the ML compatibility removal, and bug fixes.
.NET 11 Preview 1 doesn’t include any new Visual Basic language features or breaking changes. Browse the full release notes for details.
ASP.NET Core & BlazorOnRowClick EventRelativeToCurrentUriConfigureConnection for Interactive Server ComponentsIHostedService Support in Blazor WebAssemblyIOutputCachePolicyProvider
.NET MAUIBrowse the full release notes for all of this and more.
Windows FormsThis release focused on quality improvements. A full list of changes can be found in the release notes.
Windows Presentation Foundation (WPF)This release focused on quality improvements, including fixes for Fluent window backdrop and background in Windows 10. A full list of changes can be found in the release notes.
Entity Framework Core
Container Images.NET 11 Preview 1 does not introduce new container image features. Browse the full release notes for details.
Get startedTo get started with .NET 11, install the .NET 11 SDK.
If you’re on Windows using Visual Studio, we recommend installing the latest Visual Studio 2026 Insiders. You can also use Visual Studio Code and the C# Dev Kit extension with .NET 11.
The post .NET 11 Preview 1 is now available! appeared first on .NET Blog.