System.Net.Http does not behave as an OOB package when used with System.Net.Http.Formatting

[neoaisac]

This issue has been created to separate it from the conversation in issue #17770.

As explained there, when using System.Net.Http v4.0.0.0 as distributed by the .NET Framework 4.6.1, everything works correctly.

When updating the reference to the NuGet-distributed package for System.Net.Http v4.1.0.0 (here: https://www.nuget.org/packages/System.Net.Http/) the code fails at runtime whith the below exception:

[VerificationException: Method System.Net.Http.CloneableExtensions.Clone: type argument 'System.Net.Http.Headers.MediaTypeHeaderValue' violates the constraint of type parameter 'T'.]
System.Net.Http.Formatting.MediaTypeConstants.get_ApplicationJsonMediaType() +0
System.Net.Http.Formatting.JsonMediaTypeFormatter..ctor() +79
System.Net.Http.Formatting.MediaTypeFormatterCollection.CreateDefaultFormatters() +49
System.Web.Http.HttpConfiguration..ctor(HttpRouteCollection routes)
...

When reverting to the out-of-the box v.4.0.0.0 version it works as expected without problems.

Therefore, version 4.1.0.0 is not an OOB package as it breaks the functionality of other packages that relate to this one.

[neoaisac]

To expand on my above comment, the problem seems to be with the type System.ICloneable (source here: http://aspnetwebstack.codeplex.com/sourcecontrol/latest#src/System.Net.Http.Formatting/CloneableExtensions.cs).

It seems that corefx's implementation uses a custom-made ICloneable interface, therefore not meeting the type argument requirements of that class. (See corefx's custom-made internal ICloneable here: https://github.com/dotnet/corefx/blob/d0dc5fc099946adc1035b34a8b1f6042eddb0c75/src/System.Net.Http/src/Internal/ICloneable.cs).

I have tried to reference this one, though and I can't see it being used, so I may be wrong. But the error persists so it must be something related to this interface and how corefx uses it in this library.

[davidsh]

cc: @ericstj @stephentoub

[stephentoub]

cc: @danmosemsft, @KrzysztofCwalina
This appears to be due to the lack of ICloneable in .NET Core.

[neoaisac]

I would think so too, but then this disrupts the whole definition of OOB package, then.

[ericstj]

I wasn't aware that any type-subsetting was done with System.Net.Http.dll. Indeed if that exposes different surface area than the reference assembly in the package, and it has the same name, that's a breaking change that needs to be fixed.

[ericstj]

Indeed if I diff the targeting pack with the nupkg reference assembly I see this difference: https://gist.github.com/ericstj/5db3de3de78c249b1138601eb9a79423#systemnethttpheaders

[JohnGalt1717]

Just a heads up but this isn't the only issue with cross compatibility. System.IdentyModel.Tokens.Jwt is also borked completely and breaks existing .NET 4.6 solutions that worked with the old version and you're pushing this broken stuff on nuget.

[davidsh]

@ericstj Should I assign this issue to you since it has to do with packaging, etc.? Not sure how to solve this OOB issue.

[ryanrust]

This issue is definitely causing problems for users of packages that have added targetFramework usage of .NETStandard to their nuspec files. We make use of AutoMapper extensively in our project and and are running into this issue with the latest update.

[ericstj]

This isn't about packaging, as i pointed out the contract is missing ICloneable. That needs to be added back, at least to the desktop implementation you're providing out of band.

@danmosemsft and @stephentoub are adding this back to contract surface area but that won't fix this case since that will have to be in a new NETStandard version that old desktop profiles won't support.

The best fix here is for you to cross compile System.Net.Http as a desktop assembly, built against the desktop targeting pack, and make sure you implement ICloneable in that implementation.

[davidsh]

This should be fixed now with dotnet/corefx#10716.

[petersondrew]

Is there a timeline on when this fix will be pushed to Nuget?

[davidsh]

This will be part of the .NET Core 1.1 release. I believe the timing is within a few months. There will be a preview pushed to NuGet before the actual RTM (stable packages) pushed to NuGet.

cc: @richlander, @leecow can comment on release timeframe for .NET Core 1.1

[leecow]

We're shooting to have the 1.1 Preview available in October. Watch the usual channels (@dotnet on Twitter and https://blogs.msdn.microsoft.com/dotnet/) for the official announcement and details.

[jahmai-ca]

Couldn't this be fixed in isolation of 1.1? This is affecting us and it seems like it'd affect a good chunk of people referencing NETStandard and System.Net.Http.Formatters together, not great to leave broken for months.