Looks like 3.0 drops support for .NET Standard?

[samsmithnz]

This is a pity, I was using this package in a Unity project and now I'm locked into v2.x. Are there specific features available in the .NET 6+ only 3.0 that make it better? Where can I read more about this decision? Or is it only #2098?

[JimBobSquarePants]

.NET Standard barely supports SIMD intrinsics which means poor performance. In addition it adds a huge maintenance burden to library since API availability in that standard is much less than in .NET 6.

The .NET Standard experiment at Microsoft was abandoned with the development of .NET 5

https://devblogs.microsoft.com/dotnet/the-future-of-net-standard/

[JimBobSquarePants]

Not going to happen.

Adding .NetStandard (especially a legacy version!) back provides us as the library developers absolutely no benefit and great cost.

We are not Microsoft. We have less than a handful of people contributing code to these libraries. It’s absolutely absurd to expect us to provide the same level of support.

Unity are actively migrating to .NET Core https://blog.unity.com/engine-platform/unity-and-net-whats-next and if your use case requires sticking with old legacy technology then you can continue to use an older version of the ImageSharp library.

[PrzemyslawKlys]

I understand. The legacy version should be enough, but I am assuming that once some security bugs will be found it will become a very high risk to use it as I don't expect you to fix any bugs.

[JimBobSquarePants]

If there is a specific security issue we may fix it (we have fixed critical issues before) or better yet you may submit a fix.

However. We are not responsible for the legacy technology you use and should not be expected to cater for it.

[greatawesome]

I'm not sure I'd call .NET Framework legacy, considering that it will be supported by Microsoft well after .NET 10 is out of support (let alone .NET 6 and 8).

However it is definitely stuck as far as features and performance goes. Using 2.x for the Framework like a reasonable compromise in this case.

[JimBobSquarePants]

I'm not sure I'd call .NET Framework legacy, considering that it will be supported by Microsoft well after .NET 10 is out of support

It's absolutely legacy. It's only supported due to previous support obligations provided that tie it to Windows support.

[djrecipe]

I develop some cross-platform software components and we just migrated to ImageSharp after Microsoft announced they are dropping System.Drawing, so this stings a bit.

However, I understand why you wouldn't want to support the highly constrained (and confusing) environment of .NET Standard 2.0.

I guess we'll just have to internalize ImageSharp 2.3.0 assemblies for now...

[djrecipe]

@JimBobSquarePants Does using ILMerge to internalize your assemblies into our commercial software component invalidate your Apache License clauses?

Internalizing your assemblies allows us to maintain .NET Standard 2.0 compatibility while still permitting our users to still use ImageSharp 3+.

[JimBobSquarePants]

Your company would have to purchase a license but the transiant Apache clause would still stand for your downstream users.

[djrecipe]

Thanks mate, the Microsoft blog you posted is very enlightening as well.

[woutware]

I would like to add another vote for .NET standard support, it is not deprecated. I have a few customers who are in environments that consist of a mix of .NET framework and different .NET Core versions. And the thing is: .NET framework will be supported until 2030 (https://blog.inedo.com/dotnet/demystifying-lts/), which is longer than .NET 6.0 and even .NET 8.0. Furthermore, .NET Standard will be supported by future .NET versions as well. So it is ideal for users who need to consume libraries from a variety of .NET versions in their organization.

If I speak for my customers, this flexibility in consuming from a variety of .NET versions is high on their wish list, but SIMD intrinsics really isn't on that wish list at all (not saying nobody is interested in SIMD intrinsics). Their absolute first priority is to have a System.Drawing alternative, not SIMD. We all would like .NET Framework to go away, but it is going to be around until 2030 at least, and who knows if they'll prolong it even.

Also recommended reading: https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-0. The recommendation for libraries is to use .NET standard 2.0 to allow consuming from both .NET framework and .NET 5.0+ versions. It also says explicitly: .NET Standard not deprecated.

[br3aker]

Their absolute first priority is to have a System.Drawing alternative, not SIMD.

ImageSharp performance and performance of almost all popular image processing software/libraries rely on SIMD or some other form of hardware acceleration. System.Drawing relies on it. Customers may not know it but they actually need it.

I personally don't see any problems for .net standard consumers staying on ImageSharp 2.X and below.

[woutware]

If bug fixes are provided for 2.x, I wouldn't mind, that would just mean there being 2 separate development paths. But I don't have the impression that 2.x will be maintained any further.

I mean, it's not the end of the world, as System.Drawing exists for .NET framework. However this would force a number of library consumers into maintaining 2 development paths, rather than a single library being subject to this. There are consumers out there for whom .NET standard will be convenient for quite some time, unlike the suggestion of obsoletion by the blog post.