cli-sidecar targets net9.0 — consider aligning to net10 (cli-tekla/cli-revit are correctly pinned to host runtimes)

[pawellisowski]

Summary

cli-sidecar targets net9.0 while the standalone CAD-host CLIs that can track the
latest runtime (cli-rhino, cli-sketchup) are on net10.0-windows. Since
cli-sidecar is an out-of-process tool (reflection/extraction, NativeAOT — it does not
load into any CAD host), it can move to net10 for consistency.

Correction to the original report: cli-revit (net8) and cli-tekla (net48) are
correctly pinned and must not be bumped — see below.

Target frameworks

Project	TargetFramework	Bump to net10?
cli-rhino/cli-rhino.csproj	net10.0-windows	already net10
cli-sketchup/cli-sketchup.csproj	net10.0-windows	already net10
cli-sidecar/cli-sidecar.csproj	net9.0	yes — standalone tool, not host-bound
cli-sidecar/Tests/*, Ingest/Generator/Tests/*, FixtureAssembly	net9.0	yes (with the above)
cli-revit/Sidecar/cli-revit.csproj	net8.0-windows	no — pinned
cli-revit/AwareRevit/AwareRevit.csproj	net8.0-windows	no — pinned
cli-revit/Shared/Shared.csproj	net8.0	no — keep aligned with Revit
cli-tekla/cli-tekla.csproj	net48	no — pinned

Why cli-revit and cli-tekla are pinned (not lagging)

These talk to the CAD host directly through its API, in-process, so they are bound to
the host application's runtime:

• Tekla Open API assemblies target .NET Framework 4.8 IL → cli-tekla must be net48.
• Revit 2025+ runs on .NET 8 → cli-revit (and its in-process AwareRevit
  plugin + Shared) must be net8.

Bumping either would break in-process loading against the host. The only project free to
track the latest runtime is the out-of-process cli-sidecar.

Recommendation

• Bump cli-sidecar (+ its test/fixture/generator projects) net9.0 → net10.0.
• Leave cli-tekla (net48) and cli-revit (net8) as-is.

Notes

Found while standing up a downstream app (tekla-plugin-generator) that mirrors
aware-aeco conventions. Original version of this issue incorrectly listed cli-revit as
lagging; corrected here.