CamelCase serialization: retarget net10.0, cache the options instance, add the web preset

[vladimir-pecanac-main]

Sample update for Using System.Text.Json for Camel Case Serialization, which is being rewritten and republished.

The article's title is also being repaired in the same pass: an automated retitle on 2026-07-20 took the page from 687 impressions a day to 230 (down 67%) while the whole site fell 25% over the same windows, and position slipped 7.4 to 9.0, so the new title is a repair of measured damage rather than an experiment.

What changes in json-csharp/CamelCaseSerialization

• Both projects retarget net7.0 to net10.0. net7.0 is out of support and the framework version was the article's only version string.
• Test packages to current stable (read from the NuGet API on 2026-08-30): Microsoft.NET.Test.Sdk 18.9.0, xunit 2.9.3, xunit.runner.visualstudio 4.0.0, coverlet.collector 10.0.1. They were three years old (17.3.2 / 2.4.2 / 2.4.5 / 3.1.2).
• JsonSerializerExtensions keeps one static readonly JsonSerializerOptions instead of constructing a fresh instance inside each method. JsonSerializerOptions caches the serialization metadata it builds per instance; measured on net10.0 with a counting JsonNamingPolicy, five serializations of the same four-property type cost 4 ConvertName calls through one shared instance and 20 through a fresh instance per call.
• DeserializeFromCamelCase<T> now returns T?. JsonSerializer.Deserialize<T> returns T? and both projects have <Nullable>enable</Nullable>, so the old signature raised warning CS8603: Possible null reference return.
• Program.cs demonstrates new JsonSerializerOptions(JsonSerializerDefaults.Web), the preset ASP.NET Core already applies, with a covering test. The rewritten article gains a section answering "does ASP.NET Core camelCase by default?", and that claim needed a runnable counterpart here.
• ExtensionTests had its xUnit assertion arguments reversed. All five calls read Assert.Equal(actual, expected); the signature is Assert.Equal(expected, actual), so a failure would have named the wrong value as expected. Swapped, and Assert.Equal(result.IsActive, true) became Assert.True(result.IsActive).

Person.cs and PersonWithAttributes.cs are untouched: the nullable properties are deliberate and the article explains why they are there.

Build and tests

dotnet build -c Release: 0 errors, 1 warning. dotnet test -c Release: 3 passed, 0 failed (was 2, plus the new web-preset test). SDK 10.0.302, runtime 10.0.10.

The one remaining warning is pre-existing and deliberately left alone: Program.cs(27) CS8602 on personFromString.FirstName, where JsonSerializer.Deserialize<PersonWithAttributes> returns a nullable. Those exact lines are quoted verbatim in the article's JsonPropertyName section, which this rewrite does not change, so touching them here would put the sample and the published snippet out of step. It is a separate, article-visible edit.