Re-evaluate supported .NET products / C# language version #1424
Comments
|
,NET Framework will be supported for the foreseeable future and it's only .NET Standard 2.0 compliant., So, .NET Standard 2.0 should be supported. Any types introduced because of .NET Standard 2.0 should provide implicit conversions and overloads for .NET (6+) types. |
|
On the other hand, I think there's an increasingly good case for dropping .NET Framework support, especially if you can keep an older version "supported" for perhaps an extended amount of time to offer a version that keeps working on .NET Framework. As more and more .NET releases come out, the gap between them and and .NET Framework keeps growing, making it impossible (or incredibly painful) to take advantage of the new features being offered. Locking to .NET Standard 2.0 (2.1 is a completely dead end, don't even look at it) is an anchor holding back actual innovation. |
|
.NET Standard 2.1 was a band-aid in the evolution process. It was never supposed to exist, but some runtimes were late to move to .NET 5.0. You have to consider the cost of keeping older versions supported against having conditional code for newer versions. even if with limited features or capabilities. ,NET Framework (.NET Standard 2.0) will be supported, at least, while Windows Server 2022 is supported, which is Oct. 31 2031. |
|
Problem is that ms slowly stopping support .NET Standard 2.0 properly in modern nuget packages and slowly go away from it For example: long story short: I would recommend support directly: |
|
I'd say remove .NET Framework support completely for v8.0 onwards, and just target whatever is the then currently supported LTS version, as long as 7.x (ehich would be the last .NET Framework supported release) continues to get bugfixes backported as appropriate. |
What evidence do you have of that? All supported versions of .NET Framework are fully .NET Standard 2.0 compliant. That should be the target if it meets all needs. Otherwise, it should be the lowest .NET Framework version. .NET Framework will be around for a long time. .NET Framework 3.5 SP1 is supported until 2029. Imagine for how long .NET Framework 4.8 will be supported. |
|
you can check my screenshot above about warning for support and testing some additional articles: |
|
@Romfos, that screenshot is referring to .NET Core 2.0, not .NET Standard 2.0. |
|
@paulomorgado this screenshot related to .net standard support for some runtimes like .net 5, .net core 3.1, .net fx .4.6.1 |
|
NetFx461 was declared mostly, but not fully implementing .NET Standard 2.0. But 4.6.2 and forward are. And those are the ones supported. .NET Core 3.1 and .NET 5.0 are no longer supported. But they do fully implement .NET Standard 2.0. I can't see any of your claims in there. What am I missing here? |
|
that is the one of the problem. you can check links from my post above note: no difference for .net standard 2.0 support for net fx 4.6.1 and 4.6.2 (probably you mixed up it with 4.7.2) |
|
@Romfos - please provide a CONCRETE example of what you're stating, using the latest version 7 alpha of this library. In other words, I should be able to clone a repository, run The first article to which you link here talks about issues with The second article to which you link, does bring up some interesting points. |
let me try to explain State of .NET Standard 2.0 in 2023/2024:
As you can see most of .NET Standard runtimes (except of NET FX + .NET 6+) are no longer actively developed, depreciated or will be depreciated soon How Microsoft see future of .NET Standard: Packages that Microsoft are planning to stop supporting for .NET Standard:
Issues with .NET Standard in 2023/2024:.NET Standard is now meaningless (https://andrewlock.net/stop-lying-about-netstandard-2-support/) Original idea of .NET Standard: if runtime support .NET Standard of specific version and library support it then you can run this library on this runtime How it works in 2023:
Benefits from multitargeting (.NET FX, .NET 6) instead of .NET Standard in 2023:
My private opinion:
|
|
@stephentoub could you please help share your opinion about this, appreciate it |
|
@Romfos, you really should research a bit more. .NET Standard is not a runtime. |
|
Hello all. I'm from the .NET team and should be the right person to comment on the above. I agree with most of what @Romfos mentioned here. Similarly to PCLs (portable class libraries), .NET Standard is an API contract that is executed on specific runtimes. The runtimes that are currently in-support are mentioned above. As you can see, the in-support runtimes that we as the .NET team focus on are .NET >= 6 and .NET Framework >= 4.6.2. Here's an overview of types of packages that the .NET team publishes:
While some of our components actively move away from .NET Standard, others that we call "broad-reach ecosystem packages" keep their .NET Standard support to avoid disrupting the .NET ecosystem. While we in the past recommended to leverage .NET Standard for a shared codebase, we nowadays recommend to multi-target for .NET Framework and .NET in order to be able to target the latest API surface area on .NET while still supporting .NET Framework. This effectively means that you want to at least target the minimum in support runtimes: |
Mainly because .NET Standard 2.0 is frozen and won't have anything more added to it and all new APIs and innovation are in .NET. Starting with .NET 6.0, the runtime is also the standard. |
lukebakken
changed the title
|
Not commenting on the rest of the discussion about which TFMs we should support here, but the specific impetus of this was that For example, with this .csproj: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net8.0;net6.0;netstandard2.0</TargetFrameworks>
<LangVersion>12</LangVersion>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>
<ItemGroup Condition="$(TargetFramework) == 'netstandard2.0'">
<PackageReference Include="System.Memory" Version="4.5.5" />
</ItemGroup>
</Project>
this compiles: using System;
using System.Buffers;
using System.Collections.Generic;
using System.Linq;
namespace MemoryPoolLib;
public class MyMem : MemoryPool<byte>
{
internal readonly byte[] _buffer = new byte[4096];
private readonly List<Block> _blocksAvailable = [];
private const int DefaultSize = 8;
public override int MaxBufferSize => 1024;
public override IMemoryOwner<byte> Rent(int minBufferSize = -1)
{
int size = minBufferSize > 0 ? minBufferSize : DefaultSize;
var block = _blocksAvailable.FirstOrDefault(b => b.Size >= size);
Block newBlock = new(block.Start, size);
_blocksAvailable.Remove(block);
if (block.Size > size)
{
Block leftoverBlock = new(block.Start + size, block.Size - newBlock.Size);
_blocksAvailable.Add(leftoverBlock);
}
return new RentedBlock(this, newBlock);
}
protected override void Dispose(bool disposing) { }
internal void Return(Block block)
{
// TODO: merge with other contiguous blocks
_blocksAvailable.Add(block);
}
}
public record struct Block(int Start, int Size) { }
public class RentedBlock : IMemoryOwner<byte>
{
private readonly MyMem _pool;
private readonly Block _block;
private readonly Memory<byte> _slice;
internal RentedBlock(MyMem pool, Block block)
{
_pool = pool;
_block = block;
_slice = ((Memory<byte>)_pool._buffer).Slice(_block.Start, _block.Size);
}
public Memory<byte> Memory => _slice;
public void Dispose()
{
_pool.Return(_block);
}
}I was able to compile this with the .NET 8 SDK, and then reference the NuGet package with Mono's msbuild on a .NET 4.8 project, and it worked just fine. Also, the .NET 8 project that consumes this NuGet package compiles just fine and doesn't add the extra System.Buffers package. |
|
@iinuwa thank you for taking the time to dig in. |
Version 7 of this client supports
netstandard2.0, which prevents the use of features likeMemoryPool.Before shipping version 8, supported frameworks and C# language version should be re-evaluated.
Discussion: #1347 (comment)
The text was updated successfully, but these errors were encountered: