Obsolete WebRequest, ServicePoint and WebClient #41400
Conversation
|
Tagging subscribers to this area: @dotnet/ncl |
| } | ||
|
|
||
| [Obsolete("Serialization is obsoleted for this type. https://go.microsoft.com/fwlink/?linkid=14202")] | ||
| [Obsolete(Obsoletions.WebRequestMessage, DiagnosticId = Obsoletions.WebRequestDiagId, UrlFormat = Obsoletions.SharedUrlFormat)] |
There was a problem hiding this comment.
HttpClient does not support file URIs
There was a problem hiding this comment.
Do we have an alternative api for fie URIs?
It will warn even I remove this line if the FileWebRequest is created by WebRequest.Create() / CreateDefault.
There was a problem hiding this comment.
The closest API we have is for a user to call Uri.LocalPath and use File.Open. It should still be obsoleted, but a message of "use HttpClient" doesn't make sense.
aik-jahoda
force-pushed
the
jajahoda/obsolettewebrequest
branch
from
dc85370 to
11bb04e
Compare
| <IgnoreForCI Condition="'$(T | ||
| argetOS)' == 'Browser'">true</IgnoreForCI> |
There was a problem hiding this comment.
Looks like there is an unnecessery weird line break:
'$(T
argetOS)'
|
/backport to release/5.0 |
|
Started backporting to release/5.0: https://github.com/dotnet/runtime/actions/runs/229111119 |
ghost
locked as resolved and limited conversation to collaborators
|
@aik-jahoda Because the type itself isn't obsoleted, the API ref docs don't show it as being obsolete. This doesn't seem like a good user experience for the docs. How much would the extra warnings affect customers if we added the Obsolete attribute to the type as well? |
7 participants
This PR obsoletes only construction methods to reduce amount of warning and focus to entry point of usage of the obsoleted classes.
One of the PR for #33125