paulirwin commented on issue #1041: URL: https://github.com/apache/lucenenet/issues/1041#issuecomment-2515026825
> The .netstandard 2.0 target greatly simplifies things for framework developers that develops around lucene. By "framework developers" do you mean developers of frameworks-as-libraries that depend on Lucene.NET, or ".NET Framework" developers? I suppose both apply, although note that we are still going to have our net462 build for .NET Framework users. I'll let @NightOwl888 speak to the performance, since he mentioned it at #1040. One challenge with having to claim a performance penalty is because of the difficulty of actually using the netstandard2.0 target directly. Any .NET Framework version is going to prefer our net462 build over netstandard2.0, and any out-of-support .NET (Core) 3.0-7 is going to prefer our netstandard2.1 build (and then of course, .NET 8+ would use our net8.0 build). I suppose we could create some benchmarks that transitively depend on us through a netstandard2.0 library to force that, which would emulate some real-world transitive scenarios that could cause this. In either case, after thinking through it more, I do think we can reconsider this for post-4.8. One scenario is that users may be consolidating their shared logic that uses Lucene.NET into a netstandard2.0 class library to i.e. ease a transition to modern .NET from .NET Framework, which was common practice several years ago in the early days of modern .NET, even though they would likely be better served today by multi-targeting instead (or, better yet, finishing the transition to modern .NET). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@lucenenet.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
