Skip to content

Update BinaryFormatter obsoletion plan for net8 #293

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Apr 11, 2023

Conversation

GrabYourPitchforks
Copy link
Member

Updating the list of obsoletions for .NET 8, bringing a few more in and pushing some out to .NET 9.

The primary reason for doing this is to provide a better experience for developers. Compared to the original plan, this should result in fewer overall warnings being observed, and the warnings which are observed should be more directly actionable.

@yaakov-h
Copy link
Member

yaakov-h commented Apr 1, 2023

Would this include corresponding changes for roslyn-analyzers and the Exception code snippet in Visual Studio?

IIRC serialization code is still included in the snippet, and omitting those functions can trigger CA2237 and CA2229 (which would be conflicting with SYSLIB0050).

@GrabYourPitchforks
Copy link
Member Author

@yaakov-h CA2237 and CA2229 are still useful. If you do still need to implement ISerializable for some reason (e.g., you need to interoperate with legacy code), then CA2237 and CA2229 ensure you're following the standard way of doing it.

The Exception code snippet will not be changed. I asked the owners about this last week before posting the plan, including that it will begin to produce compiler warnings, and they stated there are no plans to update the snippet in the coming version. I was going to include in the release notes that you can simply delete that constructor to make the warning go away.

@ReubenBond
Copy link
Member

I see that FormatterServices.GetUninitializedObject is being made obsolete. Can we safely assume RuntimeHelpers.GetUninitializedObject will remain?

Orleans respects NonSerializedAttribute, so we will need to add some other, equivalent attribute if it's deprecated. That's not a big issue.

@GrabYourPitchforks
Copy link
Member Author

Can we safely assume RuntimeHelpers.GetUninitializedObject will remain?

Yes. I'm not aware of any plans to deprecate or hide this API.

@huoyaoyuan
Copy link
Member

The Exception code snippet will not be changed.

The whole code snippet infrastructure need an update. A lot portion of them are only applicable to C# 2.0-4.0. Please push a feature request to the owners!

De-conflict against new warning codes introduced during JSON work
Copy link
Member

@jeffhandley jeffhandley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The updated plan looks good to me. I just have one suggestion for getting rid of an "I" statement.

Co-authored-by: Jeff Handley <jeffhandley@users.noreply.github.com>
@GrabYourPitchforks GrabYourPitchforks merged commit 7fb3a35 into dotnet:main Apr 11, 2023
@GrabYourPitchforks GrabYourPitchforks deleted the bf_obs branch April 11, 2023 05:50
GrabYourPitchforks added a commit to dotnet/runtime that referenced this pull request Apr 11, 2023
- Move BinaryFormatter obsoletions to type-level
- Introduce SYSLIB0050 and SYSLIB0051 obsoletion waves
- Remove some dead code

Ref: dotnet/designs#293
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants