-
Notifications
You must be signed in to change notification settings - Fork 5.5k
-
Following up on the thread about the new support adding in System.IO.Hashing that will support our needs for CRC-64/NVME and CRC-64C. I was able to integrate the .NET 11 preview 3 version of System.IO.Hashing in the AWS .NET and use it for checksums to S3. Thanks for adding the support.
I am getting the compiler warning that this hasn't been tested on .NET 8 the currently latest target for the AWS SDK we build for. I was hoping this being in a .NET Standard 2.0 project I would be good. My rough thinking is we do a minor version bump of the SDK in November to switch to this. At that point the build targets for the SDK would be:
.NET Framework 4.7.2
.NET Standard 2.0 (We need this for PowerShell)
.NET 8
.NET 11
By the time the new System.IO.Hashing ships will I be safely able to use the new work across these targets? That would be the best and I can drop a native dependency library we use as the bandaid today. The fallback would be to use it only for .NET 11, that would be sad because the .NET Framework and .NET Standard 2.0 targets are not going away anytime soon.
Beta Was this translation helpful? Give feedback.
All reactions
-
🚀 1
Replies: 2 comments 2 replies
-
Thanks a bunch, @normj! .NET 8 and .NET 9 will both hit end-of-life in November when .NET 11 is released (putting only .NET 10 and .NET 11 in support at that time), but I'll defer to @bartonjs on whether netstandard is a possibility here.
Beta Was this translation helpful? Give feedback.
All reactions
-
System.IO.Hashing has a netstandard2.0 library, and that is what would get run on .NET 8. I'm not sure where the nuget warning comes from (this is the first I've heard of it), but it is true that we don't run the tests on .NET 8. So what that really means is that it's possible that we've called a method that's defined in netstandard2.0, and works on Framework (where we test) and in .NET 10/11 (where we test), but that it was implemented as PNSE for .NET 8.
For CRC calculations, it's not a thing I'd really be worried about.
Beta Was this translation helpful? Give feedback.
All reactions
-
Understand about .NET 8 and 9 being end of life. We generally let you guys encourage the community to move off end of life versions but don't remove build targets till our metrics show the usage has hit some minimum bar.
I guess what I'm hoping since the code is in a .NET Standard 2.0 package that it would be valid to use in any target that supported .NET Standard 2.0.
Just in case it isn't clear I am grateful for the added support and we will use it no matter what. I'm just trying to understand if I can remove all of our legacy stuff we do.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
<SuppressTfmSupportBuildWarnings>true/false is actually moving the legal and technical risk onto the user, as in: Yes, the .NET Standard DLL is there. Yes, it will load netstandard variant on runtime versions lower than 'explicitly supported .NET versions' per the compatibility philosophy of .NET. But this specific version of the library (v11) was built and tested primarily for .NET 10/11. If you run it on .NET 8 and it crashes, you're on your own; unless you check this box to say you're okay with that.
where explicitly supported .NET versions in this case are .net10 and 11 per:
% ls ~/.nuget/packages/system.io.hashing/11.0.0-preview.3.26207.106/lib
net10.0 net11.0 net462 netstandard2.0It seems to have shifted from a philosophy of "binary compatibility is enough" to "active testing on modern runtimes is required for official support".
Beta Was this translation helpful? Give feedback.