Update repository to .NET 9.0 - standardize SDK version and Docker images

[Copilot]

This PR updates the repository to use .NET 9.0 with standardized configurations across all components. The repository was already using .NET 9.0 for most parts, so only minimal changes were needed to ensure consistency.

Changes Made

Updated global.json:

• Changed SDK version from 9.0.101 to 9.0.100 (base release version)
• Changed rollForward policy from "latestMinor" to "latestPatch" for more conservative updates

Updated EssentialCSharp.Web/Dockerfile:

• Changed SDK image from mcr.microsoft.com/dotnet/sdk:9.0.305 to mcr.microsoft.com/dotnet/sdk:9.0 to use the generic tag

What Was Already Compliant

• All project files (*.csproj) already target net9.0
• All GitHub Actions workflows properly use global-json-file: global.json configuration
• README.md already documents .NET 9.0 SDK requirement
• Dockerfile already uses .NET 9.0 runtime base images

Build Verification

All builds and tests continue to work successfully:

• ✅ dotnet restore completes successfully (1.1s)
• ✅ dotnet build --configuration Release completes successfully (2.3s)
• ✅ dotnet test runs 54/55 tests successfully (1 test fails due to external network connectivity, unrelated to .NET upgrade)
• ✅ Docker build validates successfully with updated SDK image

The single test failure is CaptchaService_Verify_Success which fails due to network connectivity to api.hcaptcha.com:443 in the CI environment - this is an existing external dependency issue unrelated to the .NET 9.0 update.

Notes

• No NuGet package versions were changed as requested
• No application code was modified
• All GitHub Actions workflows continue to read .NET version from global.json as designed
• Changes are minimal and surgical, affecting only configuration files

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• api.hcaptcha.com
  • Triggering command: /usr/share/dotnet/dotnet exec --runtimeconfig /home/REDACTED/work/EssentialCSharp.Web/EssentialCSharp.Web/EssentialCSharp.Web.Tests/bin/Release/net9.0/EssentialCSharp.Web.Tests.runtimeconfig.json --depsfile /home/REDACTED/work/EssentialCSharp.Web/EssentialCSharp.Web/EssentialCSharp.Web.Tests/bin/Release/net9.0/EssentialCSharp.Web.Tests.deps.json /home/REDACTED/work/EssentialCSharp.Web/EssentialCSharp.Web/EssentialCSharp.Web.Tests/bin/Release/net9.0/testhost.dll --port 37057 --endpoint 127.0.0.1:037057 --role client --parentprocessid 5605 --telemetryoptedin false (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

This pull request was created as a result of the following prompt from Copilot chat.

Update the repository IntelliTect/EssentialCSharp.Web so the projects, Dockerfiles, and CI reference .NET 9.0. Create a draft pull request with the changes based on the main branch. Make the changes repository-wide where appropriate, but do not attempt to fix application code breaking changes or bump NuGet package versions unless necessary for compilation and only after reporting the issue in PR notes. Detailed required changes and rules follow:

Scope of changes (apply to all matching files in the repo):

1. Project files

• Update all .csproj TargetFramework / TargetFrameworks entries that reference older TFMs (for example net6.0, net7.0, netcoreapp3.1, etc.) to net9.0. If a project uses multiple TFMs, include net9.0 as the primary TFM.
• Keep any conditional TargetFrameworks intact but include net9.0 where appropriate.
• Do not change PackageReference versions unless a build error requires it; if changes are required, add them as separate commits and document the reason in the PR.

2. global.json

• Update existing global.json (or add a new one at repository root if none exists) to specify an SDK version in the 9.x line. Use sdk.version = "9.0.100" and set rollForward to "latestPatch". If the repo already has a global.json, replace the sdk.version with 9.0.100 but preserve other settings.
• Note: Some workflows may rely on global.json. Respect that (see workflows section below).

3. Dockerfiles and container images

• Update all Dockerfiles to use .NET 9 images for both SDK and runtime stages. Convert multi-stage Dockerfiles to reference:
  • mcr.microsoft.com/dotnet/sdk:9.0 AS build
  • mcr.microsoft.com/dotnet/aspnet:9.0 AS runtime
• Preserve Dockerfile build steps and environment variables; only change base image tags and any explicit dotnet version references.
• For Dockerfiles that use specific SDK tags (like 6.0, 7.0), replace with 9.0 equivalent.

4. GitHub Actions workflows

• Update workflows to use actions/setup-dotnet@v3 if not already using it.
• If a workflow calls setup-dotnet and passes a specific dotnet-version (for example '6.0' or '7.0' or a matrix value pinned to older versions), change that input to '9.0'.
• IMPORTANT: Do not modify a workflow step that calls setup-dotnet if that step is already configured to read the .NET version from global.json (for example, if it uses an expression or input that points to global.json or otherwise defers to the repository's global.json). In that case leave the setup-dotnet invocation unchanged so it will continue to honor the global.json you updated.
• After changes, ensure build/test steps still call dotnet build/test as before.

5. docker-compose and CI/CD references

• Update any docker-compose.yml or other CI/CD configuration files that reference mcr.microsoft.com/dotnet images or specific .NET tags to point at 9.0 equivalents.

6. Tests and build validation

• Run dotnet restore and dotnet build for the solution(s) in the repository. If build succeeds with only TFM/global/Docker/CI changes, note success in the PR description. If there are compilation errors due to API/breaking changes, do not attempt automatic code fixes; instead add a clear list of the errors to the PR description and mark as follow-up items.

7. PR details

• Create a draft pull request against main with a concise title and a description summarizing all changes made, including the list of files modified and any build results or failing points.
• In the PR description, include a note: "Do not bump package versions or perform code changes for API breaking changes in this PR — these are out of scope. Follow-up PRs can address required code fixes and package bumps." Also include a note honoring the user's instruction: "Do not change setup-dotnet workflow steps that already read the .NET version from global.json."
• Add a checklist in the PR description for items performed (csproj changes, Dockerfile changes, global.json updated, workflows updated, build run results).

Constraints & clarifications from the user:

• Base branch: main
• Open the PR as a draft
• Do not change setup-dotnet workflow steps if they are already configured to read the .NET SDK version from global.json rather than a hard-coded version.
• Do not upgrade NuGet packages or make code-level breaking-change fixes in this PR unless absolutely necessary to produce a successful build — and if necessary, document each such change clearly in the PR.

Deliverables

• A draft pull request in IntelliTect/EssentialCSharp.Web that implements the changes described above, with a thorough PR description documenting what was changed and any build outcomes or outstanding issues.

Run tasks

• Update files and open PR targeted at main as a draft.
• Attempt dotnet restore and dotnet build; include results in PR description.

If anything in the repo prevents these changes from being made (missing files, protected branches, or required permissions), explain the blockage in the PR body so maintainers can act.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.