Should MTConnect.NET-HTTP-AspNetCore add net8.0 to its TFM matrix?

[ottobolyos]

@PatrickRitchie, a small TFM-matrix question I'd like a steer on before opening a PR.

libraries/MTConnect.NET-HTTP-AspNetCore/MTConnect.NET-HTTP-AspNetCore.csproj currently targets netcoreapp3.1;net5.0;net6.0;net7.0 for Release and net6.0 for Debug. Its ProjectReference deps (MTConnect.NET-HTTP, MTConnect.NET-Common) target net8.0 on Debug, so the project doesn't build standalone on a stock .NET 8 SDK — dotnet build libraries/MTConnect.NET-HTTP-AspNetCore/... exits with NU1201: Project MTConnect.NET-HTTP is not compatible with net6.0 … supports: net8.0.

I noticed it while wiring docfx for the documentation-site PR (#157). Every other shipped library produces an API-reference page; this one is the only library docfx can't load, because there's no bin/Debug/net8.0/MTConnect.NET-HTTP-AspNetCore.dll on disk.

Three plausible directions, none of which I want to pick unilaterally:

1. Widen the matrix — add net8.0 to both Release and Debug TFM lists. Keeps the legacy TFMs and unblocks the docs build. The smallest possible change.
2. Trim the legacy TFMs — drop net5.0, net6.0, and net7.0 (all out of support) and standardise on netcoreapp3.1;net8.0. Lighter matrix; anyone still on net5–net7 loses official support.
3. Hold the matrix as-is — accept the docs gap. The library appears in docs/api/index.md as the sole excluded one, with a one-line pointer.

Happy to draft whichever direction you'd prefer — they're all small csproj edits plus, in (1) and (2), a re-run of the docfx pipeline. Just want your call before opening a PR.

[PatrickRitchie]

@ottobolyos Yes that is fine to include .NET 8 in the MTConnect.NET-HTTP-AspNetCore project. I don't think that project should really even be needed anymore as it was replaced by the MTConnect.NET-AgentModule-HttpServer.

[ottobolyos]

@PatrickRitchie, thanks for the steer.

I'd like to ask two follow-ups on the back of the deprecation hint, then I'll line the work up to match whichever you pick.

• If MTConnect.NET-HTTP-AspNetCore is genuinely superseded by MTConnect.NET-AgentModule-HttpServer, the cleanest ending is to remove the project from the repo (and the umbrella NuGet metadata) outright rather than maintain a still-shipping-but-prefer-the-other shim. Would you rather (a) widen the TFM matrix as a quick fix so the docs site picks the project up, then have a separate removal PR follow after one release with a 'still works on net8.0' exit ramp for any current consumer, or (b) skip the widening and go straight to a removal PR, on the basis that anyone still consuming the project today already pins an older release tag?
• If a removal PR is the right call, would you rather author it yourself—the NuGet-publish stop and migration-note voice naturally lives with you—or shall I draft it (csproj removal, sln pruning, README pointer to AgentModule-HttpServer, a CHANGELOG entry) and let you adjust? I'm happy either way.

Whichever direction you pick, I'll align the docs-site exclusion note in #157 to match—either by dropping the 'the only excluded library' caveat, or by keeping it with a pointer to the removal PR.

[ottobolyos]

@PatrickRitchie, circling back on the two follow‑ups from my previous comment—the docs-site PR (#157) is now ready in shape, and the only remaining edit on it is the AspNetCore‑excluded note in docs/api/index.md, which I'd like to align with the deprecation direction you pick rather than guess.

[PatrickRitchie]

@ottobolyos It is ok to remove the MTConnect.NET-HTTP-AspNetCore project completely from the repo. That project is no longer needed. If you can draft a removal PR that would be helpful. I will take care of the Nuget package.

The docs site is looking great!

Thanks!