Skip to content

Restore compatibility with .NET 9.0#208

Open
quis wants to merge 4 commits into
mainfrom
restore-net-9.0
Open

Restore compatibility with .NET 9.0#208
quis wants to merge 4 commits into
mainfrom
restore-net-9.0

Conversation

@quis
Copy link
Copy Markdown
Member

@quis quis commented Mar 20, 2026

Since appveyor doesn’t have .NET 10 we need to also publish for .NET 9

This commit makes sure we are building and testing against both everywhere. To make this simpler I have removed the flags from the Makefile and let the target versions be defined canonically in the *.csproj files.

The only change to make .NET 9.0 work was specifying <LangVersion>14.0</LangVersion> when building the tests. .NET 9.0 uses CSharp version 13.0, which is missing some of the assertion features we need in the tests (probably since dropping NUnit). But I think this should be fine because Appveyor will be using the packaged code, not compiling it from source.

quis added 3 commits March 20, 2026 12:29
Since appveyor doesn’t have .NET 10 we need to also publish for .NET 9

This commit makes sure we are building and testing against both
everywhere. To make this simpler I have removed the flags from the
`Makefile` and let the target versions be defined canonically in the
`csproj` files.

The only change to make .NET 9.0 work was specifying `<LangVersion>14.0</LangVersion>`
when building the tests. .NET 9.0 uses CSharp version 13.0, which is
missing some of the assertion features we need in the tests (probably
since dropping NUnit). But I think this should be fine because Appveyor
will be using the packaged code, not compiling it from source.
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR aims to restore build/test/publish compatibility on environments that don’t have a .NET 10 SDK available (notably AppVeyor) by multi-targeting .NET 9 in addition to .NET 10, and simplifying build commands to rely on canonical target frameworks in the project files.

Changes:

  • Multi-target GovukNotify and GovukNotify.Tests for net9.0 and net10.0.
  • Remove explicit framework overrides in the Makefile so dotnet build/test/pack uses the TFMs defined in *.csproj.
  • Update changelog with a new 9.0.0 entry describing restored .NET 9 support.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File Description
src/GovukNotify/GovukNotify.csproj Adds net9.0 to TFMs and bumps package version to 9.0.0.
src/GovukNotify.Tests/GovukNotify.Tests.csproj Adds net9.0 to TFMs and forces LangVersion to 14.0.
Makefile Removes -f net10.0 / custom TargetFrameworks overrides so commands build all TFMs by default.
CHANGELOG.md Adds 9.0.0 entry describing restored .NET 9 support.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread Makefile
Comment on lines 28 to +33
build-release: ## Build release version
dotnet build -c=Release -f=net10.0
dotnet build -c=Release

.PHONY: build-package
build-package: build-release ## Build and package NuGet
dotnet pack -c=Release ./src/GovukNotify/GovukNotify.csproj /p:TargetFrameworks=net8,net9,net10 -o=publish
dotnet pack -c=Release ./src/GovukNotify/GovukNotify.csproj -o=publish
Copy link

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the projects now multi-targeting net9.0;net10.0, running dotnet build/dotnet pack without specifying a framework will attempt to build/pack all TFMs. This will break environments that don’t have a .NET 10 SDK available (which is the motivation for this PR). Consider adding a Makefile variable (e.g., TFM?=net9.0) to allow building/packing just net9.0 on constrained CI, or ensuring CI installs/pins the required SDK so the default targets work everywhere.

Copilot uses AI. Check for mistakes.
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. We want to build all TFMs

Comment thread CHANGELOG.md
Comment on lines +5 to +6
<TargetFrameworks>net10.0;net9.0</TargetFrameworks>
<Version>9.0.0</Version>
Copy link

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TargetFrameworks now includes net10.0, but the repo’s AppVeyor pipeline runs dotnet test/dotnet pack without installing a .NET 10 SDK (see appveyor.txt / publish.cmd). On a machine with only .NET 9 (or earlier) installed this will fail with NETSDK1045 (cannot target .NET 10). Consider making net10.0 conditional on the SDK version/CI environment, or installing/pinning a .NET 10 SDK via global.json/CI setup, so AppVeyor can still build/test/pack.

Copilot uses AI. Check for mistakes.
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 2de7a9b

<TargetFrameworks>net10.0</TargetFrameworks>

<TargetFrameworks>net10.0;net9.0</TargetFrameworks>
<LangVersion>14.0</LangVersion>
Copy link

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting LangVersion to 14.0 will require a compiler/SDK that understands C# 14. If CI/AppVeyor is limited to the .NET 9 SDK (as noted in the PR description), this is likely to fail at compile time with an invalid language version. Prefer removing the override, or making it conditional on the installed SDK version; if specific tests depend on newer syntax, it would be safer to rewrite those assertions to be C# 13-compatible.

Suggested change
<LangVersion>14.0</LangVersion>

Copilot uses AI. Check for mistakes.
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It’s fine, this is test code so we’re not shipping it to consumers

@paul-dorsetcouncil
Copy link
Copy Markdown
Contributor

@quis I assume this has got stuck on dependencies which is fine but is there any update on a likely release date? My understanding is that you don't need to update every dependent application to use the latest so could it be released so compatible applications can be patched and then release a patch release later for the apps that were stuck on old versions of .NET?

Basically allowing people to patch .NET 10 now and patch .NET 9 and below later?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants