Auto-detect installed .NET SDK version for generated C# project files

[Copilot]

Generated and boilerplate C# .csproj files hardcoded a specific TFM (net8.0 or net10.0), requiring manual edits when using a different SDK and causing version mismatches between the generated library and test projects.

Changes

• generate.py — Added _detect_dotnet_framework() that runs dotnet --version and returns the active TFM (e.g. net10.0), falling back to net8.0. Updated --target_framework default to use it, so generated .csproj files automatically target the installed SDK.

• run_tests.py — Added the same detection helper. C# build_dir now uses the detected TFM instead of the hardcoded net10.0. Code generation passes --target_framework <detected>. dotnet build passes -p:BuildTargetFramework=<detected>.

• StructFrameTests.csproj — Replaced hardcoded <TargetFramework>net8.0</TargetFramework> with an intermediate property so the test runner can override it without the NuGet restore phase ignoring the override (a known limitation of -p:TargetFramework=):

<BuildTargetFramework Condition="'$(BuildTargetFramework)' == ''">net8.0</BuildTargetFramework>
<TargetFramework>$(BuildTargetFramework)</TargetFramework>

net8.0 remains the minimum fallback for manual builds on systems without dotnet on PATH.

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[rijesha]

Instead of targeting a dotnet version cant you target netstandard2.0 or netstandard2.1

[rijesha]

@copilot

[Copilot]

Instead of targeting a dotnet version cant you target netstandard2.0 or netstandard2.1

Targeting netstandard isn't directly feasible with the current codebase — attempting a netstandard2.1 build surfaces three incompatibilities:

1. static abstract interface members (IStructFrameMessage, ProfileProviders) — C# 11 feature only supported at runtime in .NET 7+; not part of netstandard.
2. System.Runtime.CompilerServices.IsExternalInit (init-only setters / records in generated messages) — added in .NET 5; requires a polyfill for netstandard.
3. System.Threading.Channels (StructFrameSdk.cs) — not in the netstandard2.1 surface area without a separate NuGet package.

Additionally, the test project (StructFrameTests.csproj) is an executable (OutputType: Exe), which cannot target netstandard at all — it must always target a concrete runtime like net8.0.

Fixing the three issues above would require non-trivial changes to the boilerplate (removing/polyfilling modern C# features). The auto-detection approach in the current PR avoids that by keeping the code targeting netX.0 but automatically picking the installed SDK version at generation and build time.