Obsolete old HTTP APIs

[scalablecory]

ObsoleteAttribute will be getting an update to support diagnostic IDs and URLs to help IDEs better manage obsolete API usage.

We should consider annotating WebRequest and WebClient with this. I frequently see asks for help with HTTP in .NET, and it's not uncommon to find them using one of these APIs without knowing we prefer them use HttpClient instead.

Something like

    [Obsolete(DiagnosticId="BCL1234", UrlFormat="https://aka.ms/obsoletedotnethttp")]
    public class WebRequest // Also: HttpWebRequest, FtpWebRequest, FileWebRequest (aka *WebRequest)
    {
    }

    [Obsolete(DiagnosticId="BCL1234", UrlFormat="https://aka.ms/obsoletedotnethttp")]
    public class WebClient
    {
    }

I would not want to create excessive warnings for users porting Framework apps to .NET 5, so this is predicated on IDE/compiler being updated to allow ignoring specific diagnostic IDs application-wide.

• Obsolete WebRequest, ServicePoint and WebClient #41400 - Runtime obsoletion
• Deprecate service point for server certificate dotnet-api-docs#4731
• WebRequest deprecation docs#20310
• Redirect https://aka.ms/dotnet-warnings/SYSLIB0014 link to: https://docs.microsoft.com/en-us/dotnet/core/compatibility/fx-core#webrequest-is-not-recomended-for-new-development (a dedicated SYSLIB documentation page was created instead)

[karelz]

@scalablecory can you please provide guidance / options here? (the latest status of this feature)

[jeffhandley]

I left some feedback on #41526 that likely applies to all of the obsoletions here. I'll take a look at the other PRs though.

[karelz]

Fixed in 6.0 in PR #41400

Note: Porting to 5.0 was rejected this late in the game -- see #41526

[aik-jahoda]

Reopening to help track the documentation.

[jeffhandley]

When this is worked on to track the documentation, please also see #41759, where I provided some other feedback.

[gewarren]

Should this have been closed by dotnet/dotnet-api-docs#4731? The literal comment is partially fixes #33125. The dotnet/docs PR is still in draft, and the aka.ms link wasn't updated. However, with dotnet/docs#23915, perhaps it should be redirected to the new SYSLIB0014 article instead.

[jeffhandley]

Probably not -- that might have been a false positive auto-close because of fixes #33125.

I do think this will get wrapped up with dotnet/docs#23915 though, and when the SYSLIB0014 page is published, we will need to update the aka.ms link. I'll reopen this to make sure it gets tracked.

[jeffhandley]

The documentation page is in place and the aka.ms link is configured to point to it.