Bug in System.Net.Http.StringContent on Windows 11?-CodePudding

I have the below code that has been running just fine for a couple years now on .NET 6. My development environment is a Windows 10 VM and Visual Studio 17.4.2. I recently set up a new Windows 11 VM with Visual Studio 17.4.2. This same .NET 6 code will compile just fine on that new dev machine but when I run it in Visual Studio, the creation of StringContent is failing. It’s not throwing an exception, but I can clearly see when debugging that the StringContent has no content byte array, just the headers. On both dev machines, System.Net.Http.dll is the same exact version. Here the info on that:

Assembly Name: System.Net.Http

Assembly Version: 6.0.0.0

File Version: 6.0.1122.52304

Path: C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.11\ref\net6.0\System.Net.Http.dll

Here is my code:

var requestUriWithQuery = string.Concat(requestUri, "?", query);

var httpContent = new StringContent(JsonConvert.SerializeObject(content), Encoding.UTF8, "application/json");

var requestMessage = new HttpRequestMessage(HttpMethod.Post, requestUriWithQuery);

requestMessage.Content = httpContent;

I was expecting the code to execute successfully on the Windows 11 dev machine as it does on the Windows 10 dev machine. I've spent 8 hours on this and am stumped on what's wrong.

CodePudding user response：

The difference in the two screenshots is just that on the first system non-public members are hidden by default in the debugger while they are shown by default on the second machine.

You can view the non-public members on the first machine by clicking on the little arrow in front of the "non-public members" text.

The difference between the two machines is the setting "Just my Code" in the debugger settings. It influences (among other things) whether non-public members of classes that are not part of your current solution are shown in the debugger by default or not.

So, the difference you see is just different visualization by the debugger. The data in the StringContent object is the same and there doesn't seem to be a real problem.

If you see a problem at run-time, you should try to find more details about why it happens and post a new question with more details on the actual problem.