-
Notifications
You must be signed in to change notification settings - Fork 5.2k
[release/6.0] Move 2 Drawing APIs that are not implemented in netfx to net6.0 or later #60371
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
Conversation
|
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
|
Tagging subscribers to this area: @safern, @tarekgh Issue DetailsThis was discovered with the new Customer ImpactIn 6.0 we added two new graphics APIs for better performance, but these were added to the netstandard2.0 implementation which in NuGet packages that's the ref assembly as well. These APIs are not part of the netfx implementation and that could cause runtime problems if for example a library targeting netstandard2.0, used these APIs and then a net472 application consumed this library, it would fail with TestingUnit tests, RiskLow, the I'm just bringing the old behavior before the APIs were added and conditioning these APIs to NET 6 or greater.
|
| public static System.Drawing.Graphics FromImage(System.Drawing.Image image) { throw null; } | ||
| [System.ComponentModel.EditorBrowsableAttribute(System.ComponentModel.EditorBrowsableState.Never)] | ||
| [System.Runtime.Versioning.SupportedOSPlatformAttribute("windows")] | ||
| #if NET6_0_OR_GREATER |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
decided to use ifdefs on the ref assembly for simplicity of the change and because ref assemblies sources shouldn't change during servicing, so this doesn't harm any possible experience with GenAPI.
src/libraries/System.Drawing.Common/ref/System.Drawing.Common.cs
Outdated
Show resolved
Hide resolved
|
And @joperezr perhaps |
| /// </summary> | ||
| [EditorBrowsable(EditorBrowsableState.Never)] | ||
| #if NET6_0_OR_GREATER | ||
| [Obsolete(Obsoletions.GetContextInfoMessage, DiagnosticId = Obsoletions.GetContextInfoDiagId, UrlFormat = Obsoletions.SharedUrlFormat)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did we consider making this change for netcoreapp3.1 and later instead of net6.0 and later? That could make it so the Obsolete message reaches people earlier: those that update the package without retargeting. The package builds for netcoreapp3.1 as well as net6.0 and moving this change from netstandard2.0 to netcoreapp3.1 instead of net6.0 might reach more folks (and be a smaller difference from what we've already shipped in previews).
I'm fine either way, but I'd like this to be considered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with including it in netcoreapp3.1. I'll update the PR accordingly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done 😄 Thanks for the suggestion.
|
Feel free to send the tactics mail today, you might cc me and Eric. |
ericstj
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm
|
Presumably this will also go into main? |
|
Yes. I will port it once we merge. |
This was discovered with the new
Microsoft.DotNet.Compatibilitytool: #60306 (comment)Customer Impact
In 6.0 we added two new graphics APIs for better performance, but these were added to the netstandard2.0 implementation which in NuGet packages that's the ref assembly as well. These APIs are not part of the netfx implementation and that could cause runtime problems if for example a library targeting netstandard2.0, used these APIs and then a net472 application consumed this library, it would fail with
MissingMethodExceptionat runtime.Testing
Unit tests,
PackageValidationandAPI Compat.Risk
Low, the I'm just bringing the old behavior before the APIs were added and conditioning these APIs to .NET Core 3.1 or greater.