.net 10 support

[Larocceau]

.net 10 is coming out later this year, so it would be good to get started on support on it. I would be interested in having a go at it, but that would probably be in a few weeks; given the dev guide it should not be too hard

As for now the issue on supporting .net 9 is still open #4237, is there actually anything that needs to be done there still?

[smoothdeveloper]

Thanks @Larocceau, I closed the .net 9 issue as the PR for support was merged.

If you want to give a shot to extend for .net 10 support, feel free to make a PR and reach out for assistance.

Based on previous experience, minor adjustments to few files, and adding a simple test case is good enough for things to work.

[Numpsy]

Something like https://github.com/fsprojects/Paket/compare/master...Numpsy:Paket:net10 ?

(Doesn't quite work at the moment because the tryNormalizeVersion function turns the '10' in 'net10-windows' into '1.0' and fails the tests)

[granicz]

Hi @smoothdeveloper , any plans on fixing+merging the above PR?

[halcwb]

Anybody have any idea when paket will be able to support .net 10?

[forki]

It does already in alpha channel. We just need a couple of more people to confirm that everything is OK.

Casper @.***> schrieb am Sa., 15. Nov. 2025, 18:36:

halcwb left a comment (fsprojects/Paket#4296) https://github.com/fsprojects/Paket/issues/4296#issuecomment-3536707275

Anybody have any idea when paket will be able to support .net 10?

— Reply to this email directly, view it on GitHub https://github.com/fsprojects/Paket/issues/4296#issuecomment-3536707275, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAOANDIVIHWMX6IN6ANQFL345QBNAVCNFSM6AAAAAB5TNTFOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMZWG4YDOMRXGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[halcwb]

@forki Thanks! I am trying it and using framework: net10.0 it builds. Only I get a lot of

warning NU1510: PackageReference System.Reflection.Metadata will not be pruned. Consider removing this package from your dependencies, as it is likely unnecessary

warnings.

I can switch the pruning feature off. But it seems a very useful feature. Is this something that will be available via paket as well?

[yaakov-h]

I've tried 10.0.0-alpha011 and there is some weird interaction going on with test projects and paket.

With NuGet, if I add my test packages (nunit3, nunit3testadapter, microsoft.net.test.sdk) I get a project.deps.json that includes microsoft.net.test.sdk as a dependent package, same as on previous runtimes.

With Paket, that is missing from my project.deps.json, so our in-house test environment isn't detecting it as a test project. It still works with VS IDE and dotnet-test CLI. There's nothing obvious in MSBuild XML or binlogs as to how this reference is getting omitted during the build.

This is after needing to set <RestoreEnablePackagePruning>false</RestoreEnablePackagePruning> to disable the pruning as per above, though I wonder if the test package is somehow getting pruned regardless.

[wnewbery]

@forki Thanks! I am trying it and using framework: net10.0 it builds. Only I get a lot of

warning NU1510: PackageReference System.Reflection.Metadata will not be pruned. Consider removing this package from your dependencies, as it is likely unnecessary

warnings.

I can switch the pruning feature off. But it seems a very useful feature. Is this something that will be available via paket as well?

@halcwb

I was trying to work out what exactly in intended here by that warning? One thing I noticed that felt a bit odd is looking at a project in Visual Studio it lists a bunch of these under "Packages" (e.g. System.Buffers ...\.nuget\packages\system.buffers\4.6.1) but it seems they are already under "Microsoft.NETCore.App" (e.g. C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\10.0.0\ref\net10.0\System.Buffers.dll). Which doesn't even show the same version number.

Trying to follow it through, paket.lock lists all of these, but only a few actually got added to the project and then caused the prune warnings. They were in MyProject.csproj.net10.0.paket.resolved as like System.Buffers,4.6.1,Transitive,Main,false,true,false,true,. Not sure on the meaning of the booleans there (the paket.dependencies doesn't contain System.Buffers explicitly).

Is this warning saying these are "part of the framework" and should never be added as packages? They should only be added when targeting older versions for compatibility (e.g. if needed System.Buffers in a .NET Framework 4.8 project)?

But it didn't happen when I quickly made a clean project with a couple of NuGets that depend on System.Buffers indirectly, so I am not sure on what triggers that. So possible that is a mess in our 100 projects which have been upgraded by many people over a couple decades.

[halcwb]

@forki Thanks! I am trying it and using framework: net10.0 it builds. Only I get a lot of warning NU1510: PackageReference System.Reflection.Metadata will not be pruned. Consider removing this package from your dependencies, as it is likely unnecessary warnings. I can switch the pruning feature off. But it seems a very useful feature. Is this something that will be available via paket as well?

@halcwb

I was trying to work out what exactly in intended here by that warning? One thing I noticed that felt a bit odd is looking at a project in Visual Studio it lists a bunch of these under "Packages" (e.g. System.Buffers ...\.nuget\packages\system.buffers\4.6.1) but it seems they are already under "Microsoft.NETCore.App" (e.g. C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\10.0.0\ref\net10.0\System.Buffers.dll). Which doesn't even show the same version number.

Trying to follow it through, paket.lock lists all of these, but only a few actually got added to the project and then caused the prune warnings. They were in MyProject.csproj.net10.0.paket.resolved as like System.Buffers,4.6.1,Transitive,Main,false,true,false,true,. Not sure on the meaning of the booleans there (the paket.dependencies doesn't contain System.Buffers explicitly).

Is this warning saying these are "part of the framework" and should never be added as packages? They should only be added when targeting older versions for compatibility (e.g. if needed System.Buffers in a .NET Framework 4.8 project)?

But it didn't happen when I quickly made a clean project with a couple of NuGets that depend on System.Buffers indirectly, so I am not sure on what triggers that. So possible that is a mess in our 100 projects which have been upgraded by many people over a couple decades.

@wnewbery thanks for the useful suggestion. I could just first remove all dependencies and then add them as like in a fresh new solution with projects.

[halcwb]

P.S. If anybody knows of a tool to resolve all transient dependencies and show the pruned dependency tree, I would love to use that. Currently, I am trying to figure out my project dependency graph manually.