[release/11.0.1xx-preview1] Add .NET MAUI baseline manifests for .NET…

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

Release

Here's a summary of what's new in ASP.NET Core in this preview release:

• EnvironmentBoundary component
• Label component for forms
• DisplayName component
• QuickGrid OnRowClick event
• Relative navigation with RelativeToCurrentUri
• GetUriWithHash() extension method
• BasePath component
• MathML namespace support
• InvokeVoidAsync() analyzer
• IComponentPropertyActivator
• SignalR ConfigureConnection for Interactive Server components
• Unified startup options format for Blazor scripts
• IHostedService support in Blazor WebAssembly
• Environment variables in Blazor WebAssembly configuration
• Blazor WebAssembly component metrics and tracing
• Enable container support in Blazor Web App template
• OpenAPI schema support for binary file responses
• IOutputCachePolicyProvider
• Auto-trust development certificates in WSL

ASP.NET Core updates in .NET 11:

• What's new in ASP.NET Core in .NET 11 documentation.
• Roadmap

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 in v1.28

• Bumped the winget version to 1.28 to match the package version.
• Additional options for limiting the size of log files.

New Feature: 'source edit'

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.

New Feature: 'list --details'

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.

Bug Fixes

• Portable Packages now use the correct directory separators regardless of which convention is used in the manifest
• --suppress-initial-details now works with winget configure test
• --suppress-initial-details no longer requires --accept-configuration-agreements
• Corrected property of Font experimental feature to accurately reflect fonts as the required setting value

What's Changed

• Bump version to 1.28 by @florelis in #5787
• Move to latest 7.4 PS SDK by @JohnMcPMS in #5811
• Enable MultiProcessorCompilation by @Trenly in #5804
• Remove mention of WinGet Insider program from the README by @florelis in #5832
• Ignore ReleaseStatic outputs and clean intermediates by @JohnMcPMS in #5848
• Make Repair-WGPM a COM-aware cmdlet and rework version retrieval by @JohnMcPMS in #5842
• Unregister signal handler by @JohnMcPMS in #5861
• Support associating export units with packages in subdirectories of install location by @JohnMcPMS in #5859
• Send host geo to sandbox by @JohnMcPMS in #5873
• Update C++ nuget package references using new scripts by @JohnMcPMS in #5877
• Update platform toolset by @florelis in #5882
• Extract event log for potential crash info by @JohnMcPMS in #5807
• Update CODEOWNERS to include winget-developers by @florelis in #5891
• Fixes for VS2026 by @florelis in #5896
• Additional logging limitations and control by @JohnMcPMS in #5888
• Use hybrid CRT linkage instead of full static by @JohnMcPMS in #5913
• Enable source reference to get thread globals for off-thread logging by @JohnMcPMS in #5780
• Fix JSON, missing closing brace by @doterik in #5924
• Test host for in-proc COM module validation by @JohnMcPMS in #5910
• Add sleep to allow background threads to quiesce by @JohnMcPMS in #5933
• Allow suppressing configuration output on test by @Trenly in #5794
• Enable Explicit toggling for sources (i.e. Enable/Disable) by @dkbennett in #5904
• Fix fuzz build by @JohnMcPMS in #5932
• Normalize directory separators when adding packages to path by @Trenly in #5796
• Add sleep to another inproc test by @JohnMcPMS in #5935
• Don't build inproc testbed for fuzzing by @JohnMcPMS in #5937
• Create schema 1.12.0 folder by @Trenly in #5944
• Fix names of 1.12 Schemas by @Trenly in #5945
• Fix Font feature property name by @Trenly in #5946
• Add check to ensure vcpkg triplets match across projects by @florelis in #5950
• Update release notes for v1.28 by @florelis in #5957
• Details output option for list by @JohnMcPMS in #5939
• PowerShell Repair enhancements by @AmelBawa-msft in #5711
• Allow inproc callers to disable termination signal handlers by @JohnMcPMS in #5958
• Add manifest version to WinGetUtilInterop by @msftrubengu in #5964
• Fixes for updating winget from winget by @JohnMcPMS in #5972
• Diagnostics and fix for pipeline test failures by @JohnMcPMS in #5975
• Escape caller in user agent header by @JohnMcPMS in #5998
• Add DSC resource list to manifest by @JohnMcPMS in #5997
• Add command builder with escaped user input by @AmelBawa-msft in #5982
• Add missing closing brace in settings.export.schema.0.1.json by @DuckDuckStudio in #6004
• Turn off PWSH UT build in Fuzzing and ReleaseStatic for all platforms by @AmelBawa-msft in #6005
• Remove experimental feature gate on source edit by @dkbennett in #6006
• Update ReleaseNotes by @florelis in #6007
• Make list details stable (1.28) by @JohnMcPMS in #6021
• Move to IReference rather than custom enum for optional bool (1.28) by @JohnMcPMS in #6024
• Apply latest localization patch (1.28) by @florelis in #6025

New Contributors

• @doterik made their first contribution in #5924

Full 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 staging¹. 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 too². How do I try to handle mistakes now?

Handling the emotional reaction

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.

Communicate

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 mistakes³, 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).

Accept that it’s going to hurt

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 up⁴.

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 projects⁵. 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 industries⁶, you should expect to make mistakes now and then, otherwise you’re likely working far too slow.