Repository navigation
Add .Net 10 Support #2192
Description
Activity
- It should already work fine. We don't need an additional TFM target to support higher frameworks. We only need to do that if there is a new feature we want to use. Regards, Marc…On Thu, 19 Feb 2026, 13:06 DevEngineReq, ***@***.***> wrote: *DevEngineReq* created an issue (DapperLib/Dapper#2192) <#2192> Currently, Dapper only supports .NET 8. Could you please also add support for .NET 10? — Reply to this email directly, view it on GitHub <#2192>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEHMBHK2X7E3VYSB7BL634MWYORAVCNFSM6AAAAACVV5ZTSGVHI2DSMVQWIX3LMV43ASLTON2WKOZTHE3DEOBZGAZDMOA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>Reacted by Frédéric Delaporte
Thank you for the response and for confirming that Dapper works correctly on .NET 10. Based on this information, we will continue using the net8.0 Dapper package in our .NET 10 applications.
From my perspective, it would be more transparent to also publish a build that targets net10.0. This would make it clear to all consumers that the package has been tested with and officially supports .NET 10.
Regards,
I don't mind adding one, but to be absolutely clear: TFMs roll forward (unless there's a hard break, but that is exceptionally rare), precisely to avoid the scenario where thousands upon thousands of libraries are suddenly unusable when a new framework comes out (and especially: for pre-release frameworks where most library authors won't want to do a GA release against a non-GA framework)
Reacted by Frédéric DelaporteThank you for your explanation. If the vendor confirms that the library works with a newer .NET version, that is generally sufficient for me :-) However, I personally feel more confident when the library is explicitly released for .NET 10, as this gives me assurance that it is officially supported by the vendor.
A version bump to denote the change would be nice.
Release 2.1.72
Reacted by Alexander Yumashev@mgravell thank you so much for this release. You are 100% correct about fresh TFM not strictly "required"
However by adding a newer TFM - we get a binary compiled against that newer BCL with performance benefits included for free (JIT optimizations, PGO, trimming etc. etc) so thanks again
All of those things are unchanged by me adding a TFM; the JIT does whatever the JIT on the final runtime does, and build things are driven by the consumer build SDK.
Literally the only benefit is making people not have to ask "does this work on .NET 10?".
@mgravell wait, hold on, I might be wrong here, but I always thought that just re-building same library on a newer SDK can emit slightly different IL code. More optimizations, like lambda caching, string interpolations, struct copying etc etc - all the stuff from Stephen Toub posts...
I mean, even if you rebuild a
net8target on a newer, net10 SDK you get this stuff for free.Again, I might be wrong. In that case - nevermind.
You're not wrong, but I don't think anything huge in this case. That's actually two categories:
- new compiler internal choices: usually apply if a new build SDK is used, regardless of the target frameworks, so: while possible, we would have gained most of that just by updating the build SDK without adding a TFM - but yes, it would have needed a rebuild
- new overload choices via methods in a new framework; possible, but nothing huge here that I'm aware of
But you're right, it is worth updating everything just to exploit every theoretical improvement.
Currently, Dapper only supports .NET 8. Could you please also add support for .NET 10?