Convert the solution to slnx - #14
Closed
henrikottesorensen wants to merge 2 commits into
Closed
Conversation
dotnet sln migrate, plus the two things that fall out of it. runtime.liblouis.crosscompile.sln is deleted rather than converted. Nothing loaded it: the build scripts pack individual csproj files, and it had not been updated to include the macOS runtime projects, so it had been quietly wrong for some time. Converting a file nobody opens would only preserve that. global.json declares an SDK floor of 9.0.200, the first release that reads slnx. This is mostly documentation: on a machine with both SDKs dotnet already picks the newer one, so nothing changes in practice. It does not buy a good error either - an unsatisfiable global.json reports that the command could not be loaded, which is no clearer than the MSB4068 an old SDK gives on an slnx. The value is that the requirement is written down where someone would look for it. Stacks on the multi-targeting change because that is what puts a .NET 10 SDK in CI. On main the workflow installs 8.0.x only, which cannot read slnx at all. Verified: build_managed_packages.sh builds, tests and packs through the slnx, on both target frameworks. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
It broke the container build: A compatible .NET SDK was not found. process "/bin/sh -c sh ./build/build_metapackage.sh" exited 145 global.json applies to every dotnet invocation in the repository, and the container runs sdk:8.0-jammy. I had reasoned about which SDK CI installs and missed that the container has its own. Nothing in the container needs a newer SDK. It packs individual project files, which any SDK handles, and never loads the solution. Only build_managed_packages.sh does, and that runs on a runner where setup-dotnet provides .NET 10. The floor is documented instead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
henrikottesorensen
changed the base branch from
main
to
feature/dotnet10-multitarget
August 12, 2026 06:27
Collaborator
Author
|
Superseded by #24. 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
2 participants
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.
dotnet sln migrate, plus the two things that fall out of it. 34 lines of GUIDs and per-configuration platform mappings become five lines:It stacks on #7 because of a hard SDK requirement
.slnxneeds an SDK of 9.0.200 or later.main's workflow installs8.0.xonly, and SDK 8 cannot read the format at all — it has nomigrateverb and fails withMSB4068: The element <Solution> is unrecognized. #7 is what puts a .NET 10 SDK in CI, so this has to follow it.global.jsondeclares the floor. Being honest about what that buys: on a machine with both SDKs installed,dotnetalready picks the newer one, so nothing changes in practice; and an unsatisfiableglobal.jsonreports "The command could not be loaded", which is no clearer thanMSB4068. The value is that the requirement is written down where someone would look for it, not that the failure becomes obvious.runtime.liblouis.crosscompile.sln is deleted, not converted
Nothing loads it. The build scripts pack individual
.csprojfiles, and grepping the repository finds no reference to it. It had also never been updated to include the two macOS runtime projects, so it had been quietly wrong for a while. Converting a file nobody opens would only have preserved that.The only consumer of a solution file is
build/build_managed_packages.sh, updated here.Verified
build_managed_packages.shbuilds, tests and packs through the.slnx, on bothnet8.0andnet10.0.global.jsonresolves to SDK 10.0.302.Note for reviewers on older tooling:
.slnxneeds Visual Studio 17.14+, Rider 2025.1+, or the .NET 9.0.200+ CLI.🤖 Generated with Claude Code