273 posts tagged with "Fixes"

I published my API and started it with dotnet publish/Dewiride.Inventory.Api.dll. It ran and it answered, and it logged SQL statements that its appsettings.json turns off. The file was right there, and nothing said it wasn't being read.

My plain-text logs came out as 2026-11-06T08:00:35.102Zinfo: Program[0], with the timestamp stuck to the log level. A TimestampFormat I'd set for JSON logs had carried over to Development. Here's why, and three ways to fix it.

#:property and #:package lines configure a one-file C# program, so they have to come before anything else in it. Mine was below a using, so the build stopped with CS9297. Moving it up fixes it.

JsonSerializer.Serialize is about as ordinary as C# gets, so Reflection-based serialization has been disabled for this application was a surprise, in a one-file program with nothing else in it. File-based apps turn this off by default. There are two ways to deal with that.

dotnet run app.cs, on a small program with a DbContext, stopped with Model building is not supported when publishing with NativeAOT. I wasn't publishing anything. File-based apps turn native AOT on by default, and one line at the top of the file turns it off.

The same burst of 600 requests crashed my API from curl and passed from PowerShell, and I nearly wrote that it only happened on one operating system. It was my PowerShell command: asked for 300 at a time, ForEach-Object -Parallel never got past 87.

The certificate is invalid was about my client certificate, the one VerifyFull needs in SslCert. I'd made it with the usual openssl req -x509, which marks a certificate as a certificate authority on a normal setup, and the driver doesn't accept a CA in that spot.

MySqlConnection.ClearAllPools() is static, so I wrote await MySqlConnection.ClearAllPoolsAsync(), and the compiler said CS0120. The async versions in MySql.Data aren't static, unlike the methods they mirror.

/health/ready said Unhealthy, and the log said with message '(null)'. No exception, and no reason. The real error is one request away: the EF Core check swallows it, and a normal request doesn't.

I put Kestrel:Limits:MaxRequestBodySize in appsettings.json, set to 1 MB, and a 2 MB request went straight through with no warning. Kestrel reads its endpoints from that section, but not its limits, so the setting looks right and does nothing.