IL2104 IL2026 TRIM and JSON with WinUI3 and newer C#

 JSON: why is C# TRIM so horrible for no reason 

Trim analysis warning IL2026: SerializeExtra.Demonstrate_Bug_Program.Demonstrate_Bug_Main(): Using member 'System.Text.Json.JsonSerializer.Serialize(!!0, JsonSerializerOptions)' which has 'RequiresUnreferencedCodeAttribute' can break functionality when trimming application code. JSON serialization and deserialization might require types that cannot be statically analyzed. Use the overload that takes a JsonTypeInfo or JsonSerializerContext, or make sure all of the required types are preserved.

In the old days, C# had a simple JSON story: always use the Newtonsoft JSON library, helpfully packaged up in NuGet, and never use anything else, ever. But then I tried making an app with WinUI3 and the more recent C# (like version 10?), and now it completely sucks, and it's ten times harder than it should be. And it's all Microsoft's fault

C# introduced a new concept: TRIM. This is a link time option. It's on by default for Release mode and off by default for Debug mode. What it does it go through your app and removes all of the "unneeded" code. The problem is that it means that the normal way Newtonsoft's JSON works doesn't work; it will just plain crash.

Note the horrific discovery mechanism for this, by the way: there you are, coding happily in a shiny new app, using shiny new features, and a switch you didn't set causes weird-ass warnings when you compile, and then your app crashes, but only when you're almost done and are now testing in Release mode.

The only solution is to switch to the System.Text.Json.JsonSerializer and Deserializer classes. But even these are completely broken with the new switch, and delightfully (sarcasm) the official Microsoft documentation guides you right into the absolute wrong way to use them.

Worse, the C# classes also guide you into the wrong way. Those shiny new templated classes? Those won't work at all.

Luckily, I've researched it so you can just jump right into the pit of success.

• When you make your SourceGenerationContext from JsonSerializerContext, always add a TypeInfoPropertyName option 
• When you call Serialize of Deserialize, you must use the non-templated versions. Pass in your object (or string, for deserialize), the typeof(yourclass) and your SourceGenerationContext.Default object. 
• Never new up a SourceGenerationContext object. When you do, it won't have the JsonSourceGenerationOptions that the Microsoft docs tell you to use
• Always specify a [JsonSourceGenerationOptions(WriteIndented = true)]. If you wanted a compressed serialization format, you'd have used Protocol Buffers, not JSON. When you use JSON, it's because your users want a human readable result, not some one-line nonsense.

See my complete project on Github for more details. The About file is particularly helpful. Look at the WeatherForecast_Fix1.cs file for full details. The bug is reported to Microsoft .NET team.

Fixing the dreaded XAML parsing failed

Fixing my XAML Parsing Failed bug (subfolders)

This is a doozy, and is about the last possible bug one would imagine in the new WinUI3 that Microsoft is pushing for us to use when making apps for Windows.

The background when you make an app using C# (and really, why wouldn't you?), you will use the XAML mini-language for describing your layout. XAML has conceptually been around for years, but Microsoft being Microsoft, they can't help but radically change it and rename it every few years. The XAML for WPF isn't the XAML for SilverLight, which isn't the XAML for UWP, which isn't the XAML for the most recent WinUI3

And a problem that a ton of people have discovered is that somewhat randomly they will write some XAML and it will just fail. But it won't fail at compile time (they do compile-time work to make it run fast; the XAML is not interpreted at runtime). Instead, it fails when your XAML page or control is displayed! The exception generally just says "XAML Parsing Error".

Well, I've figured what's going on. Like any seasoned developer, I use folders to organize my controls. Guess what programming system from a major OS company can't handled "putting a control into a folder"? That's right, Microsoft's WinUI3!

I've filed [a bug](WinUI3 (Microsoft.UI...) creates broken UserControls when creating in a sub-folder - Developer Community).

And I've got a simple repro [on GitHub](https://github.com/pedasmith/bug_WinUI3_usercontrol_in_folder_xaml_parse)

Developing on ARM64: DEP0700 failures in Debug mode

Can you solve this error message? 

DEP0700: Registration of the app failed. [0x80073CF3] Windows cannot install package NAME because this package depends on a framework that could not be found. Provide the framework "Microsoft.VCLibs.140.00.Debug.UWPDesktop" published by "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or ARM64 processor architecture and minimum version 14.0.33728.0, along with this package to install.

Background: building an existing UWP app on ARM machine

I have one of the ARM64 machines that Microsoft is big on, and of course I have a bunch of existing app (Store link). So what better thing to do than to enjoy a nice coffee in a fancy lodge here in the pacific northwest while updating the Bluetooth app to support a new device?

Except you can't deploy your debug-mode ARM64 app! It fails with the above error! 

What's do the might search engines say?

Search engines recommend the following three things:

<Dependencies>
<PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.24217.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />

</Dependencies>

Or this:

<RequiredBundles>$(RequiredBundles);Microsoft.VisualStudio.Component.UWP.VC.ARM64</RequiredBundles>

Or updating the user's .VSCODE profile. None of these work

Crappy solution found! Just run in x86 mode!

The crappy solution I eventually tried: just run in x86 mode instead of ARM64 mode. Sure, it's a waste of processor time and effort, and sure, it's a stunning indictment of Microsoft's absolute failure to actually support their own freaking devices, but it got me moving forward.

Github is both awesome and painful with VS 2026

 The old days of programming, before source control systems, was kind of dangerous. There was always the possibility of losing all your work, and there wasn't a good way to move files from one computer to another. Indeed, when I was a consultant, I paid good money for a "Jaz" drive and for a WinZip license just to be able to move files from one office to another.

GitHub integration is awesome for fixing all these problems. But it has its own particular point of view that makes it awkward for just a hobbyist programmer.

Today's problem: I added a big image to my new program that was larger than the 100 MB GitHub max. That's OK; GitHub isn't a blob storage. But correcting the problem!!!

First action: delete the large file and make a compressed copy (I don't want the compressed one to have the same name for other reasons). Result: now I can't upload my files from my computer to GitHub. Even though the file is deleted, it seems like Git really, really wants it to upload first so that it can delete it. And the upload will always fail.

Second action: read a bunch of suggestions on the internet. Result: this works, but I have to download a random python file that absolutely must not have an extension (!) and must be in a special path for Git integration. But integration isn't really needed. Result, B: it "works" but now my repo is broken. This is by design; the tool automatically unlinks my local files from the repo.

Third action: read more suggestions. And there's a completely different Git command to reset the remote (git remote add origin URL). And the first command helpfully told me the right URL to use. 

What would have helped: the Git integration in VS 2026 should include a "you added a giant new file and it's going to hurt".

TL/DR: Git is designed for Big Project and Very Knowledgeable Users. This causes problems.  

More Visual Studio and WinUI3 issues, September 2025 version

 I'm getting closer to releasing my next app (tentatively called "Simple Exporter for Bing Maps Collections"), I'm running into more silly issues with both Visual Studio 2022 and with the WinUI3 toolkit.

Error box fit-and-finish

Let's start with terrible fit-and-finish. This is the "Error" list that Visual Studio 2022 shows to help consolidate all errors. Take a look in particular at the column spacing, but also look at the vertical alignment.

The most important information is probably the description; it's squeezed into a narrow column. The project name (arguably the least important information) is given a super wide column by default. And because the description is so narrow, the critical code, file, and line number data isn't even visible. 

But wait, the fit and finish is actually worse than it appears. The actual error is that while removing some code, I removed the backing code from my .CS file but I haven't removed it from my .XAML UX file. As a reminder, XAML is the go-to for Windows UX work, and has been ever since the Windows Presentation Foundation (WPF) was created for Vista. It's the foundation (albeit with forks) for the Silverlight web plugin, it was the UX for Windows Phone 7 (and was redone for Windows Phone 8), it was the UX for the "Metro" apps in the giant Windows 8 update. 

After all this time, Visual Studio can't figure out that the code as written is in the XAML file, not the generated .g.cs file. And that with the .g.cs file having a comment saying exactly where the code is from.  

Continuing issues with the Windows model: XamlRoot

Fixing the This element does not have a XamlRoot. Either set the XamlRoot property or add the element to a tree.' exception.

One of the most common things for a developer to do is pop up a dialog box. From a quick error, to notifying that a long-running command is complete, to showing an About box, we use dialog boxes all the time. By default, they don't work.

Looking at the documentation, the C# sample code doesn't include setting the XamlRoot until very far down in the documentation. You have to set the XamlRoot is your app uses an "AppWindow" instead of an "ApplicationView". Note that the app framework is 100% boilerplate. This is the entire description of a WinUI3 project from Visual Studio 2022:

Note that "uses AppWindow" isn't mentioned. There's essentially no useful documentation on why there's this switch, or why in one framework the topmost thing is a "ApplicationView" but into another the work Application is shorter and now it's a "View". Nor does the winUI3 docs say anything about this, and in any event, AFAICT the AppWindow is marked as being preview for the last 5 years.

And let's keep on the HWND issue with Pickers

Error being solved: System.Runtime.InteropServices.COMException: 'Invalid window handle. (0x80070578)

Consider WindowNative, InitializeWithWindow

See https://aka.ms/cswinrt/interop#windows-sdk'

And the solution: add this line of code.  

WinRT.Interop.InitializeWithWindow.Initialize(savePicker, AppWindowHandleHwnd);

Micro-gripe: the URL https://aka.ms/cswinrt/interop#windows-sdk  in fact takes me to the GitHub repo for the docs, not the actual learn.microsoft.com page.

Let's unpack the terrible, terrible usability of this. For a Picker to work, it needs to know the HWND that it should be attached to. If you don't set this, you get the exception. But there's no good way (AFAICT) for a control to even know the HWND they are part off.

My eventual solution: the MainWindow.xaml.cs, in the constructor, will set a public AppWindowHandleHwnd public property that I added to my user control. Why do a push, and not have the control pull the value? Because the user control is intended to be generic: it doesn't know much at all about the environment that it's in, and certainly doesn't know anything about the application it's in. So there's no way for the control to "know" what the MainWindow is. On the other hand, the MainWindow.xaml.cs file is the program, and it certainly knows all about the underlying controls that are used by the application and knows all the requirements that the control exposes. 

Utter failures suggested by Microsoft:

Using "WinRT.Interop.WindowNative.GetWindowHandle(this)" as suggested by Retrieve a window handle (HWND) - Windows apps | Microsoft Learn . But that only works for an object of type Window and not for just any ordinary FrameworkElement-derived object like a UserControl. IMHO, "calling from a UserControl" is going to be like 99% of the time.

The error you get, BTW, is a runtime error, not a compile time error, and looks like this: 

System.InvalidCastException: 'Failed to create a CCW for object of type 'SimpleExportBingMapsCollection.BingMapsExtractorControl' for interface with IID 'EECDBF0E-BAE9-4CB6-A68E-9598E1CB57BB': the specified cast is not valid.'

And WTF is up with "Failed to create a CCW for object of type...". It's most likely a COM Callable Wrapper - .NET | Microsoft Learn. But's it's an incredibly wonky phrase to add to the exception.

As an alternative,  a Microsoft person also suggested using the VisualTree.GetParent() method, which is ridiculous. That method only returns XAML UIElement parents, and the Window isn't one of those. 

Weird issues with WinUI3 and ALT key: so many beeps!

 Like any good developer, I want my WinUI3 app to have keyboard control over the menus. And once again, the terrible fit-and-finish of the WinUI3 framework is causing problems.

This time: every time the user presses the ALT key (like they are supposed to!) Windows decides to make the program BEEP!

This is reported as this bug 4379 and 9074. Some useless comments are here.

And somehow, the code I copy-pasted said that "SetWindowSubclass" et all were all in user32.dll. That's not true; it's in comctl32.dll. And did you know that if LINK.EXE isn't in your path, that DUMPBIN won't work?

Update: thanks to castorix's comment for  issue 4379, I have a workaround. See the full file at App.xaml.cs. All you have to do is weird stuff to get an HWND (ignoring the "CoreWindow" documentation since that's just wrong) and then subclass the window, catch the WM_MENUCHAR and then tell windows to close the menu. (seriously, return MNC_CLOSE, documented as "Informs the system that it should close the active menu". Telling windows to close the menu will in fact let the user open the menu with ALT keys just like it should.

Weird issues in WebView2 / WinUI3: handling the ALT key

Applies to: WinUI3 apps with a WebView2 and a menu

Problem: Normally users press the "Alt" ("Menu") key to use an app's menu. But after the user clicks on a WebView2 (as one does; it's a common practice), all Alt keys will be swallowed up by the WebView2.

Solution: capture the 'Alt' key and use that as a trigger to move focus. 

1. In the JavaScript for the one specific page I use, add a 'keydown' event listener. When the event.key is "Alt", send a special message to the enclosing C# code using the  window.chrome.webview.postMessage method.
2. In the C# code add a WebMessageReceived event callback. When the special message is received, set the app's focus to the parent object (cast the this.Parent to a FrameworkElement)    

The problem with this solution is that the first ALT is entirely swallowed up. The user has to press ALT twice to use the menus, but only when they have clicked on the WebView2.

Interesting discoveries: weirdly, when I wrote the C# code, Visual Studio 2022 hallucinated up a solution that involved constructing real objects like a KeyRoutedEventArgs and then calling made-up methods. And, FYI, the KeyRoutedEventArg has no public constructor. 

Links:

KeyRoutedEventArgs  Random difficult work-around and this one, too 

So many issues: 721 3352  984 5772 288 951 

Weird issues in WebView2 / WinUI3: using the ms-appx: scheme

 Update your WebView2 WinUI3 code to read ms-appx:/// URLS from your Assets folder

It was the simplest of APIs, it was the most irritating of APIs. The ms-appx:/// URL scheme is one of the unheralded awesome parts of the WinRT API set. With it, there's a simple and straightforward way for an app to combine a bunch of C# code and also some useful HTML code. I'm using it this month for my (upcoming) Simple GPS Explorer app so that I can display GPS traces on an OpenStreetMap map.

The ms-appx:/// URL scheme is also one of the irritations of moving from UWP apps over to WinUI3 and whatever they're calling the framework. That's because the PMs decided that a simple straightforward way to read local assets wasn't useful in programming.

This blog post shows how to use ms-appx:/// in WinUI3 and WebView2 in just a few steps. We're going to combine two different abilities:

1. We're going to replace the ms-appx:/// in all URLs with an HTTP://msappxreplacement/ . This switches both the scheme (ms-appx: to http:) and adds in a fake host name (msappxreplacement)

2. We'll use the WebView2 SetVirtualHostNameToFolderMapping method s that every HTTP URL that goes to hostname "msappxreplacement" will instead read a file from a folder relative to the app.

Just to make life more difficult, the WebView2 navigation flow doesn't actually let you do this easily :-(. You'll need two chunks of code that do three things:

1. Replace the URI with the ms-appx: scheme with an HTTP URL that points to the msappxreplacement hostname. This must be done in the NavigationStarting event handler and requires that the original navigation be canceled and a new navigation started.

2. Set the NavigationStarting event handler on your WebView2 object

3. Update your WebView2.CoreWebView2 with a virtual hostname redirector so that all HTTP URLs that use msappxreplacement as the hostname instead just read from a local directory.

Code snippets:

NavigationStarting event handler must cancel the original navigation and instead set the source to this other place. You can't just update the URI because the StartingEventArgs ".Uri" value doesn't let you. This handles the item #1 above.

        private void UiWebView_NavigationStarting(WebView2 sender, Microsoft.Web.WebView2.Core.CoreWebView2NavigationStartingEventArgs args)
        {
            // Input URL: ms-appx:///Assets/SimpleMapLeaflet/SimpleMapLeaflet.html
            // Updated URL: http://msappxreplacement/SimpleMapLeaflet.html
            var originalUri = args.Uri;
            if (originalUri.StartsWith("ms-appx:///"))
            {
                var replacementUri = originalUri.Replace("ms-appx:///", "http://msappxreplacement/");
                args.Cancel = true; // Cancel the original navigation.
                sender.Source = new Uri(replacementUri);
            }
        }

At initialization (like as part of your control Loaded event)

    uiWebView.NavigationStarting += UiWebView_NavigationStarting;
            await uiWebView.EnsureCoreWebView2Async();
            const String assetFolder = "Assets/HtmlSubdirectory";
            uiWebView.CoreWebView2.SetVirtualHostNameToFolderMapping
             ("msappxreplacement", assetFolder, 
               Microsoft.Web.WebView2.Core.CoreWebView2HostResourceAccessKind.Allow);

This code sets up the WebView2 to divert all URLs with an "msappxreplacement" hostname to the given directory. The directory will be in the app's installation directory (assuming you have a deployable app, of course). The "uiWebView" is the WebView2 that you put onto your XAML control. This handles the item #2 and #3 above.

Hints: the folder must exist for this to work! Otherwise the SetVirtualHostNameToFolderMapping will throw an exception.

Quick gripe: none of this should be needed. There's no reason why the WebView2 shouldn't come this way out of the box. And it's super painful that the ms-appx scheme is so far from handled by WebView2 that the only place to do the replacement is in NavigationStarting event. If the scheme isn't replaced there, WebView2 will simply fail and not even try to load the URL.

Helpful links:

See https://github.com/MicrosoftEdge/WebView2Feedback/issues/212

See also: https://github.com/microsoft/microsoft-ui-xaml/issues/1967

This restriction is not mentioned in https://learn.microsoft.com/en-us/microsoft-edge/webview2/get-started/winui

A lifetime of weird issues: VSCode and more

Upleveling my gripes + making better software

People who read my blogs know that I'll write mostly about things not working: painful Bluetooth protocols, awkward APIs, and inconvenient programs. That's good, but what advice would I give someone who's looking for a plan to improve, say, VSCode for C# developers.

Count up friction points, and reduce them

A classic PM thing is to make up a metric, measure it, do some work, and declare success. And hopefully measure again, so there's before and after numbers, but weirdly, that's not valued as much as you might think.

So what are the obvious friction points for VS Code? And for reference, here's the start-up screen for my VS Code. Look at all those projects!

The "Recent" list isn't actually my recent files. There's four things listed (blinky, ConstantHtmlTraffic, GenerateWiFiQrCode, and AstronomyOnThePersonalComputer. But in reality, the last files I edited was a set of Markdown files.

The Icons on the left are random, not planned. I have a longer gripe about not meeting the Windows design language, but the icons are particularly bad. Why is the "file" icon marked as "explorer"? Why is the universal "settings" gear marked as "options"? Why is there a "command palette" and yet there's also a "tasks" which isn't a set of my tasks; it's some other commands.

The POV of the app isn't very clear. The original POV was simple: it's an editor. Now it's morphed into a container of random stuff. 

Forward and back aren't consistent. For example, go to the welcome screen, and then run Github. The welcome screen is replaced by a big GitHub screen, but the "back" button doesn't take me back.

 Friction when figuring out a next step due to tone: The explorer in-line help says: "You haven't opened a folder" which feels accusatory instead of helpful. I've opened plenty of folders in my life including folders for VS Code. I just don't have one open right now. There's a fun old anecdote from the early days of computers. The IBM engineers had a hot new (and very expensive) computer with a light marked "idle". Watson had them change it to "ready". "Idle" means that a very expensive computer is wasting money; "Ready" means that an expensive computer is ready to get to work.

Friction because extra steps are demanded but not required: The button "Clone Repository" says "Clone a repository once the Git extension is activated". But in fact, the programmer need do nothing at this point.

Random UX is harder to puzzle out. The button "Clone Repository", when clicked, instantly jumps to a random-feeling part of the screen (it overlays on top of the search bar)

Friction in decoding what dialog boxes mean: The clone repo text box (sorry, there's no better name for it) says I can "pick a repository source". AFAICT, this is then tied to the second item in the fake dialog box, where I get clone from GitHub, but only if I log in. Which is weird, because I'm already logged into GitHub

Friction in cloning the repo. After cloning a repo, I'm asked if I want to open it. That's weird; it's hard to imagine a work flow where opening the repo I just cloned isn't the right choice. 

Friction in open folder. Clicking Open Folder after cloning a repo doesn't go to the folder I just opened. A common practice in Windows is for dialogs to remember previous uses.

Builds are flaky. I asked Chat how to build one of my projects. The resulting command was incorrect (it referenced a non-existing directory hierarchy for the csproj file). When the command was provided with a correct csproj file, it didn't build. The same project builds perfectly in Visual Studio.

Frenetic UX increased anxiety without providing value. When running a build command, the terminal frantically updates a clock every tenth of a second. As an example of the opposite way of life, I present my "Low Distraction Work Timer" that's designed to be entirely non-frenetic.

Added friction from the non-standard UX. VS Code doesn't follow any of the modern Windows UX principles here. It's not effortless or calm, or notably personal (in particular it loves to turn on dark mode even though I've never turned on dark mode on anything, ever). It's not familiar, it's not complete + coherent, or any of the other principles. 

 Solution! How to make it better!

Inspired by the Quick Settings Metric.

The best way to figure out what's wrong with VS Code (or any platform) is to design some simple work flows and use the Quick Settings Metric methodology: write down every single "decision" a user would have to make.

Some example workflows include:

1. Clone a C# project, find a line of code, set a breakpoint, and debug it
2. Create a WinUI3 C# project, add the latest WebView2, and make a one-page UX with a textblock title, a variable-size webview with a button to go to a single hardwired site with a custom User-Agent, and a scrolling textblock to track the webview navigation. Verify that the user-agent is correct. 
3. Create a Blazor web page ...
4. Create a command-line app ...

 Part of the Quick Settings Metric is that the harder the "decision" the user has to make, the more points it costs. Clicking an OK button is relatively cheap; selecting from a list is more, and making the user type something in is even more. For VS Code, telling the user to "log in" but they have to type in their MSA is more expensive than the better solution of allowing users to select from their already-in-use MSA.

Wierd issues in the WinUI3 / WebView2: Solving the User-Agent problem

 TL/DR: To verify that you are setting the right user-agent, you have to check the "web resource requested" event's copy of the request headers, not the "navigation starting" event's copy. And you need to call AddWebResourceRequestedFilter.

Background: why am I setting the user-agent, and why do I need to check it?

I'm writing a simple app to parse NMEA data from a small GPS tracker (because that's what I do for fun, that's why). I'm at the part of the project where I want to make a GPS trace, and the technology I've picked is the Open Street Maps project using the leaflet JavaScript library. It's actually really nice: it works smoothly, and the integration was mostly simple.

But ... one of the requirements Open Street Maps has is that if you make an app that works against their servers, you have to use a custom User-Agent header in the HTTP requests. This makes sense: they can filter requests based off of the user-agent if needed.

After a bit of work, it's not hard to set the user-agent. But how to verify that it's correct? The easiest way was to set an event handler on the WebView2 NavigationStarted event. That event provides a CoreWebView2NavigationStartingEventArgs object that includes the request headers. I just have to iterate through them (easy-peasy) and they check the User-Agent value.

And it's not set!

Side quest #1: timing

Web searches show that people do have trouble setting the User-Agent. In particular, it must be set before you get a navigation started event. But in my app, that's not a problem.

Side quest #2: threads and services

The documentation also helpfully points out that the user-agent is thoroughly screwed up if you have multiple WebView2 objects. Each object might well share some of the underlying bits, and so when you have two WebView2 objects, and the user-agent is set differently on them, you might well have the the wrong user-agent sent. This is just dumb, but I remember from previous work with Edge that it's a pretty complex beast.

Solution: check based on the WebResourceRequested event. This requires setting the event in a different place than normal (it must be set after calling the EnsureCoreWebView2Async method). It also requires setting a WebResourceRequestFilter, which hopefully won't cause a slowdown in my app. That callback also includes all of the request headers, and those headers show the correct User-Agent. 

Links: see my question at Setting a WebView2 UserAgent isn't updated in the NavigationStarting event - Microsoft Q&A. 

 

Weird issues in Visual Studio 2022: Solving the CS0534 error when solving the Json trimming problem

 TL/DR: Visual Studio 2022 is wrong, and your code is OK

Background: I'm having to switch from the awesome NewtonSoft JSON library over to some crappy System.Text.Json library (because VS thinks that breaking everyone to support Trimming is somehow ever OK). The sample code for that is wrong, but that's OK, it points to the right code.

Except that if you copy-paste the sample code, it fails:

The error, BTW, is CS5034: 'SourceGenerationContextErrorCS0534' does not implement inherited abstract member 'JsonSerializerContext.GetTypeInfo(Type)' and also '...does not implement inherited abstract member 'JsonSerializerContext.GeneratedSerializerOptions.get' and also 'CS7035: There is no argument given that corresponds to the required parameter 'options' of 'JsonSerializerContext(JsonSerializeroptions?)'.

Solution: just recompile. It turns out that every single thing about the error is wrong. The correct solution is to "recompile your code". That's because Visual Studio 2022 is focused on everything other than the day-to-day experience of programmers.

Weird issues in Visual Studio 2022 ┄ missing publish profiles with WinUI Blank App Packaged

 

TL/DR: Desktop .NET Core apps might be missing a Publish directory because it's in the .github ignore list. The files are actually all very similar and can be copy-pasted from another project.

Background: 

A part of the .NET Core is that projects are both "built" and "published". This has apparently been around for ages. The problem is that there's a terrible split in the tooling: some parts of the tooling consider "publishing" to be essential and won't work if you don't have some publishing files set up. But other parts of the tooling consider "publishing" to be dangerous and therefore should be excluded from GitHub.

Helpful links:

Format of the .gitignore file: git-scm.com

There is no findable documentation for pubxml files. A web search shows a bunch of information related to ASP.NET

Solution:

The solution has two parts: get new version of the missing pubxml files and add them to GitHub.

1. Get new pubxml files from a new WinUI Blank App (packaged) project that you create in a temporary directory. Copy the entire PublishProfiles directory (it has to be called that for the builds to work). The directory should have three pubxml files in it.

AFAICT, the files are always the same for each project.

2. Update your .GITIGNORE file to allow the PublishProfiles directory to be saved. Warning: not all pubxml files should be put into GitHub. Some pubxml files include secret information like passwords and connection strings.

Perhaps the safest change is to add this line at the end of the .gitignore file (and remove the tabs). After the change, in your ```(project) / Properties / PublishProfiles``` directory the *.pubxml file will show up.

# 2025-07-19: shipwreck software: WinUI Blank App (Packaged) requires the win-arm64.pubxml,
# win-x64.pubxml and win-x86.pubxml files for the Release mode compile to work
# BUT pubxml files can include secret information, so we should not just allow all
# pubxml files to be added to GitHub.
!win-*.pubxml

Error messages:

These error messages pop up when building a WinUI Blank App Packaged (2025-07-18)

Code Description Project File
NETSDK1198 A publish profile with the name 'win-x64.pubxml' was not found in the project. Set the PublishProfile property to a valid file name. WinUI_Blank_App_Packaged_2025_07_15 C:\Program Files\dotnet\sdk\9.0.302\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets
NETSDK1102 Optimizing assemblies for size is not supported for the selected publish configuration. Please ensure that you are publishing a self-contained app. WinUI_Blank_App_Packaged_2025_07_15 C:\Users\USER\.nuget\packages\microsoft.net.illink.tasks\8.0.18\build\Microsoft.NET.ILLink.targets

VS: Don't start your project names with numbers!

 Weird issues in Visual Studio 2022 -- an ongoing saga

Ever get an error in a brand new project saying that "App.WinRTVtable.g.cs" is failing and that "global::WinRT is a namespace?Tearing your hair out because what in the world could you have done to make this fail?

It turns out it's your project name. When you make a WinUI Blank App (Packaged) in Visual Studio 2022, and the project name starts with a number, it makes a broken project.

Links:

GitHub project demonstrating the problem: link.

Existing bug: Build Errors when assemblyname starts with a number · Issue #1880 · microsoft/CsWinRT

The bug claims it will be fixed soon in "2.3.0", whatever that is.

Here's the dump from the Output window for building.

1>------ Build started: Project: 2_WinUI_Blank_App_Packaged_2025_07_15, Configuration: Debug x64 ------

1>C:\temp\2025\testrepos\VSBugReportSolution\2_WinUI_Blank_App_Packaged_2025_07_15\obj\x64\Debug\net8.0-windows10.0.19041.0\win-x64\intermediatexaml\WinRT.SourceGenerator\Generator.WinRTAotSourceGenerator\_2_WinUI_Blank_App_Packaged_2025_07_15.App.WinRTVtable.g.cs(4,40,4,53): error CS0118: 'global::WinRT' is a namespace but is used like a type

1>C:\temp\2025\testrepos\VSBugReportSolution\2_WinUI_Blank_App_Packaged_2025_07_15\obj\x64\Debug\net8.0-windows10.0.19041.0\win-x64\intermediatexaml\WinRT.SourceGenerator\Generator.WinRTAotSourceGenerator\_2_WinUI_Blank_App_Packaged_2025_07_15.App.WinRTVtable.g.cs(4,56,4,104): error CS0103: The name 'WinUI_Blank_App_Packaged_2025_07_15VtableClasses' does not exist in the current context

1>C:\temp\2025\testrepos\VSBugReportSolution\2_WinUI_Blank_App_Packaged_2025_07_15\obj\x64\Debug\net8.0-windows10.0.19041.0\win-x64\intermediatexaml\WinRT.SourceGenerator\Generator.WinRTAotSourceGenerator\_2_WinUI_Blank_App_Packaged_2025_07_15.App.WinRTVtable.g.cs(4,2,4,164): error CS1729: 'WinRTExposedTypeAttribute' does not contain a constructor that takes 3 arguments

1>Done building project "2_WinUI_Blank_App_Packaged_2025_07_15.csproj" -- FAILED.