Added FormUrlEncodedMediaTypeFormatter to .NetStandard version of System.Net.Http.Formatting

[YakhontovYaroslav]

No description provided.

[dnfclas]

@YakhontovYaroslav,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

[Eilon]

@dougbu it seems reasonable to have the same set of types across all the different TFMs of this one package. Are there any other types that don't appear in all the TFMs of this package?

[dougbu]

Are there any other types that don't appear in all the TFMs of this package?

FormUrlEncodedMediaTypeFormatter is the only formatter left out of the "client" assemblies, those targeting "NETCore" (not .NET Core, just portable -- Profile259) and .NET Standard.

However, the client assemblies contain a strict subset of what's in the .NET Framework assembly. I believe the original intent was to support only what we call output formatters in ASP.NET Core MVC.

In any case, the System.Net.Http namespace in the client assemblies lacks the following public types:

• ByteRangeStreamContent
• HttpContentFormDataExtensions
• HttpRequestHeadersExtensions
• HttpRequestMessageExtensions
• HttpResponseHeadersExtensions
• InvalidByteRangeException
• MultipartFileStreamProvider
• MultipartFormDataRemoteStreamProvider
• MultipartFormDataStreamProvider
• MultipartRemoteFileData
• RemoteStreamInfo

The System.Net.Http.Formatting namespace in the client assemblies lacks the following public types:

• ContentNegotiationResult
• DefaultContentNegotiator
• FormDataCollection (it's internal in the client assemblies)
• FormUrlEncodedMediaTypeFormatter (the point of this PR)
• IContentNegotiator
• IRequiredMemberSelector
• JsonContractResolver
• MediaTypeFormatterExtensions
• MediaTypeFormatterMatch
• MediaTypeFormatterMatchRanking
• MediaTypeMapping
• QueryStringMapping
• RequestHeaderMapping
• XmlHttpRequestHeaderMapping

The client assemblies don't provide either System.Net.Http.Headers type (CookieHeaderValue and CookieState). The presented APIs of the supported formatters are also subsetted e.g. removing MaxDepth properties and DataContractJsonSerializer and MediaTypeMapping support, probably due to restrictions in the underlying platform or Json.NET when targeting that platform. (Well, MediaTypeMapping doesn't appear because it's tightly linked to HttpRequestMessage.)

[dougbu]

Also, remove the #if !NETFX_CORE that's here and move typeof(FormDataCollection).IsAssignableFrom(type) || out of the conditional block here.

• make similar changes to MediaTypeFormatterCollectionTests and HttpTestData to make references to FormUrlEncodedMediaTypeFormatter unconditional.

I'm on the fence about HttpContentFormDataExtensions. Please try out adding that and HttpContentFormDataExtensionsTests), then build. Let us know how it goes

[dougbu]

@YakhontovYaroslav please edit the System.Net.Http.Formatting.NetCore.csproj file and add the same link. Then, confirm everything builds from the command line. (I suspect problems building in VS 2017 will go away as I complete work on the infrastructure.)

[dougbu]

Add similar links for FormUrlEncodedMediaTypeFormatterTests in the test projects. That may require building DerivedFormUrlEncodedMediaTypeFormatter too.

[YakhontovYaroslav]

I have managed to build both projects locally. It seems that msbuild \t:restore is not working with .NetCore(PCL) projects, but NuGet 4.3.0 restore is ok. But i still have issues running tests: xUnit.NET runner reports 0 tests found for some reason.

Thanks for your guidelines, i have added all stuff related to FormData back with last commit, but now we have 1 failing test: ReadAsFormDataAsync_HandlesFormData.
This is due to mess with HttpValueCollection and FormDataCollection having different visibility in different TFMs. FullFramework implementation uses NameValueCollection, but Core version custom implementation (see HttpValueCollection).
Why Core implementation has to UrlEncode keys and values on add (see here)? As far i know NameValueCollection does not have this behavior.

[Eilon]

@YakhontovYaroslav thanks for the update!

@dougbu do you think you could take it from here?

[dougbu]

do you think you could take it from here?

👍

[dougbu]

d86dda5

[YakhontovYaroslav]

Thanks guys, looking forward for 5.2.4 release.