[feature] Infrastructure migration to SDK v10.0

[marwannettour]

[feature] Migrate to .NET SDK 10

Context

ByteSync currently runs on a single runtime version, ensuring consistency and allowing the use of modern language and runtime features uniformly:

Project	Current TFM	LangVersion
ByteSync.Client	net8.0	default
ByteSync.Common	net8.0	default
ByteSync.ServerCommon	net8.0	default
ByteSync.Functions	net8.0	default
All 7 test projects	net8.0	default

Important

The build error CS8652 in InventoryPart.cs (use of the field keyword) is a direct symptom
of this inconsistency: ByteSync.Client targets net9 but uses LangVersion=default, which maps
to C# 13 on net9 — but the field keyword only became stable in C# 14 (net10). Migrating to
net10 + C# 14 is the clean fix; alternatively, setting LangVersion=preview is a short-term
workaround.

Goal

Migrate the entire solution to .NET 10 and align all projects on C# 14 (LangVersion=default on net10), ensuring:

• A uniform SDK across all projects (source + tests)
• Compatibility with Azure Functions v4 on .NET 10 (isolated worker)
• All NuGet dependencies updated to versions supporting net10.0

---

Scope of changes

Source projects (4)

[MODIFY] ByteSync.Client.csproj

• <TargetFramework>net9.0</TargetFramework> → net10.0
• <RuntimeIdentifiers>win-x64;linux-x64</RuntimeIdentifiers> — verify net10 RIDs still valid
• Review all NuGet packages for net10 compatible versions (Avalonia, SignalR, Azure SDK, etc.)

[MODIFY] ByteSync.Common.csproj

• <TargetFramework>net8.0</TargetFramework> → net10.0
• Update Microsoft.Extensions.Logging.Abstractions, Serilog, System.IO.Abstractions

[MODIFY] ByteSync.ServerCommon.csproj

• <TargetFramework>net8.0</TargetFramework> → net10.0
• Update Microsoft.AspNetCore.Authentication.JwtBearer (8.x → 10.x)
• Update Microsoft.Extensions.* packages (8.x → 10.x)
• Verify Azure.Identity, Azure.Storage.Blobs, AWSSDK.S3, StackExchange.Redis, RedLock.net compatibility

[MODIFY] ByteSync.Functions.csproj

• <TargetFramework>net8.0</TargetFramework> → net10.0
• <AzureFunctionsVersion>v4</AzureFunctionsVersion> — Azure Functions v4 supports .NET 10 isolated worker ✓
• Update Microsoft.Azure.Functions.Worker* packages (1.x → latest net10-compatible)
• Update Microsoft.AspNetCore.Authentication.JwtBearer (8.0.23 → 10.x)
• Update Microsoft.Azure.AppConfiguration.AspNetCore, Microsoft.Azure.SignalR
• Verify MediatR, RedLock.net, StackExchange.Redis

---

Test projects (7)

• ByteSync.Client.UnitTests — net8.0 → net10.0
• ByteSync.Client.IntegrationTests — net8.0 → net10.0
• ByteSync.Common.Tests — net8.0 → net10.0
• ByteSync.Functions.UnitTests — net8.0 → net10.0
• ByteSync.Functions.IntegrationTests — net8.0 → net10.0
• ByteSync.ServerCommon.Tests — net8.0 → net10.0
• ByteSync.TestsCommon — net8.0 → net10.0

For each: update NuGet test packages (NUnit, FluentAssertions, NSubstitute, etc.) to net10-compatible versions.

---

Key risks & things to investigate

Warning

Azure Functions .NET 10 support — As of early 2026, the isolated worker model supports .NET 10
preview. Confirm GA availability and that Microsoft.Azure.Functions.Worker ≥ 2.x supports net10.

Warning

Avalonia net10 support — Avalonia 11.x targets net8.0 libs. Verify that referencing net8
Avalonia assemblies from a net10 consumer is supported (it generally is via compatibility shim),
or wait for an Avalonia release with net10.0 TFMs.

Caution

Microsoft.AspNetCore.SignalR.Client (currently 8.0.23) — Must be bumped to 10.x.
Possible breaking changes in SignalR connection API and hub protocols.

Note

field keyword (CS8652) — Once on net10 with LangVersion=default (C# 14), this error
disappears naturally. No code change needed in InventoryPart.cs.

Note

global.json — There is currently no global.json at the repository root. Adding one that
pins the .NET 10 SDK version is recommended for reproducible builds.

---

Suggested implementation order

1. Add a global.json at the repo root to pin the .NET 10 SDK
2. Migrate ByteSync.Common first (least dependencies)
3. Migrate ByteSync.ServerCommon (depends on Common)
4. Migrate ByteSync.Functions (depends on ServerCommon)
5. Migrate ByteSync.Client (independent from server projects)
6. Migrate all test projects
7. Run full build + all tests
8. Validate the Azure Functions host starts locally with net10

---

Verification plan

• dotnet build on the full solution with zero errors
• dotnet test — all test suites green
• Manual smoke test: launch ByteSync.Client locally
• Manual smoke test: launch ByteSync.Functions locally via func start
• CI pipeline passes (if applicable)