Multi-target net8.0 and net10.0 - #7
Closed
henrikottesorensen wants to merge 1 commit into
Closed
Conversation
henrikottesorensen
force-pushed
the
feature/dotnet10-multitarget
branch
from
August 5, 2026 12:30
6716cdb to
e43267c
Compare
LibLouis.NET and the test project build for both. The extensions packages are referenced per target framework, 8.0.2 for net8.0 and 10.0.10 for net10.0, so a net10.0 consumer does not drag an older set into its dependency graph. The runtime packages stay on netstandard2.0: they carry no managed code, and netstandard2.0 is the widest thing to be compatible with. Microsoft.NET.Test.Sdk moves to 18.8.1, the first version that supports net10.0. Packing a multi-targeted project runs the cross-targeting outer build, which has no default None items, so the existing <None Update="LICENSE"> matched nothing there and the licence silently never reached the package (NU5030). The inner builds do have the item, where a second Include would be a duplicate, so both forms are present and conditioned on whether TargetFramework is set. The container's own SDK version is deliberately not touched here. It compiles C and runs dotnet pack, and which SDK does the packing barely affects the output; moving it belongs with the Dockerfile restructure that separates compiling from packing, not with the multi-targeting. Verified: both target frameworks build and pass, and the package carries lib/net8.0 and lib/net10.0 with matching per-TFM dependency groups. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
henrikottesorensen
force-pushed
the
feature/dotnet10-multitarget
branch
from
August 5, 2026 12:31
e43267c to
a83f932
Compare
This was referenced Aug 5, 2026
This was referenced Aug 12, 2026
Collaborator
Author
|
Superseded by #23. The head branch has moved from the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
LibLouis.NETand the test project build for both target frameworks.Scope changed
This originally also moved the build container to
sdk:10.0-noble. That has been dropped from this PR. The container compiles C and runsdotnet pack, and which SDK does the packing barely affects the output — these arenetstandard2.0metadata around an already-compiled binary, withIncludeBuildOutputoff. The container's SDK now moves as part of the Dockerfile restructure that separates compiling from packing, where it belongs. This PR is purely the multi-targeting.The change
The extensions packages are referenced per target framework — 8.0.2 for
net8.0, 10.0.10 fornet10.0— so a net10 consumer does not drag an older set into its dependency graph. The package ends up withlib/net8.0/andlib/net10.0/and matching per-TFM dependency groups.The runtime packages stay on
netstandard2.0. They carry no managed code, and netstandard2.0 is the widest thing to be compatible with.Microsoft.NET.Test.Sdkmoves to 18.8.1, the first version supporting net10.0.setup-dotnetinstalls both SDKs.A bug this change introduced, and its fix
Packing a multi-targeted project runs the cross-targeting outer build, which has no default
Noneitems. The existing<None Update="LICENSE">therefore matched nothing there, and the licence silently never reached the package —NU5030, at pack time rather than build time. The inner builds do have the item, where a secondIncludewould be a duplicate. Both forms are now present, conditioned on whetherTargetFrameworkis set.Worth knowing generally:
Updateon a multi-targeted project is a trap, because it behaves differently in the outer and inner builds.Verified
Both target frameworks build and pass the tests, and the packed
.nupkgcarries bothlib/folders with the right dependency groups.🤖 Generated with Claude Code