NightOwl888 commented on issue #872: URL: https://github.com/apache/lucenenet/issues/872#issuecomment-1753157532
> Just wanted to add my thoughts on the .NET Framework/Standard statement. > > I don't think .NET Framework is as legacy as one would think, that is a really sad fact but it turns out that its more difficult to migrate than what many could hope for :(. So I think there are more allot of projects out there stuck on .NET 4.X that are still maintained. Present company included :). But I wasn't thinking of dropping .NET Framework yet (although many people have suggested it). There were huge investments on .NET Framework and it will be a decade or so until it is no longer in wide use due to problems upgrading (i.e. WPF, ASP.NET WebForms, etc). > With regards to .NET Standard 2.0, I think there are many cases that one may not be aware of, I was certainly made aware as part of a Castle.Windsor discussion a while back that it's a really useful target for e.g. Library authors or if you where sitting on a "Core" version one step prior to a supported one, e.g. if one would choose to support .NET 6, 7 etc but not 5 and down, people on 5 and down could use that. So I would not cut that away so hastily. > > I know I was at least convinced by that discussion that it was to soon to discard support for it, and that perhaps one should discard support for .NET 4.X before that. (It would become supported as part of supporting .NET Standard) > > Ofc. this has to be weighed against the burden to maintain it. Well you have a point. I just looked at the details and although Xamarin is going out of support very soon, .NET Standard 2.1 doesn't support UWP. So, dropping it would be a problem for users of that platform. We support .NET Standard 2.1, which will handle any users lagging to upgrade from .NET Core 2.x - .NET 5.x and we have a .NET Framework 4.6.2 target to handle that platform. If we drop .NET Standard 2.0, we would also lose Xamarin.Android < 10.0, Xamarin.iOS < 12.16 which are now [out of support](https://dotnet.microsoft.com/en-us/platform/support/policy/xamarin) and Unity < 2021.2. .NET Standard 2.0 is the least efficient platform we support. There are performance advantages for being on a native platform (such as on `net6.0` we call the `System.Numerics.BitOperations` class that calls hardware intrinsics). As a result, 3rd party extensions to Lucene.NET (such as [Lucene.Net.Store.Azure](https://www.nuget.org/packages/Lucene.Net.Store.Azure/4.8.0-beta015)) that target `netstandard2.0` that are consumed by .NET 6.x - .NET 8.x will take a performance hit to use because although a `net6.0` target is available, when referencing the component it will downgrade to `netstandard2.0` and skip the hardware intrinsic code (or at least I think it will - need to test). They would also be stuck with this hacky weak event code to workaround the missing ConditionalWeakTable enumerator. But I guess that is more of a "don't do that" bug that we need to add a note on the README telling NuGet library developers to multi-target to avoid the slower code. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
