HttpClient 4.3.2 broken on Mono

[mattjohnsonpint]

Hopefully this is the right place to report this. If not, please move and/or let me know where to report.

HttpClient appears to be broken when running on Mono with the latest release. Consider the following:

Install-Package System.Net.Http -Version 4.3.1

using System;
using System.Net.Http;

namespace HttpClientTest
{
    class Program
    {
        static void Main(string[] args)
        {
            var client = new HttpClient();
            var response = client.GetAsync("https://www.microsoft.com/net").Result;
            Console.WriteLine(response.StatusCode);
        }
    }
}

Compile with VS 2017, targeting .NET Framework 4.6.1. Run from the Windows command line:

HttpClientTest.exe

Works, no problem. Run under Mono, and also works.

mono HttpClientTest.exe

Now upgrade to 4.3.2

Update-Package System.Net.Http -Version 4.3.2

Run again. Works on .NET Framework, but under Mono, I get a MissingMethodException.

Unhandled Exception:
System.MissingMethodException: Method 'System.Net.Logging.get_On' not found.
  at System.Net.Http.HttpMessageInvoker.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x0003d] in <09d4a140061c48849b6322067e841931>:0 
  at System.Net.Http.HttpClient.SendAsync (System.Net.Http.HttpRequestMessage request, System.Net.Http.HttpCompletionOption completionOption, System.Threading.CancellationToken cancellationToken) [0x00049] in <09d4a140061c48849b6322067e841931>:0
  at System.Net.Http.HttpClient.GetAsync (System.Uri requestUri, System.Net.Http.HttpCompletionOption completionOption, System.Threading.CancellationToken cancellationToken) [0x0000c] in <09d4a140061c48849b6322067e841931>:0
  at System.Net.Http.HttpClient.GetAsync (System.Uri requestUri, System.Net.Http.HttpCompletionOption completionOption) [0x00008] in <09d4a140061c48849b6322067e841931>:0
  at System.Net.Http.HttpClient.GetAsync (System.Uri requestUri) [0x00000] in <09d4a140061c48849b6322067e841931>:0
  at System.Net.Http.HttpClient.GetAsync (System.String requestUri) [0x00008] in <09d4a140061c48849b6322067e841931>:0
  at HttpClientTest.Program.Main (System.String[] args) [0x00007] in <8019b64f4f864b30ba0f2936c90cfab0>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.MissingMethodException: Method 'System.Net.Logging.get_On' not found.
  at System.Net.Http.HttpMessageInvoker.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x0003d] in <09d4a140061c48849b6322067e841931>:0 
  at System.Net.Http.HttpClient.SendAsync (System.Net.Http.HttpRequestMessage request, System.Net.Http.HttpCompletionOption completionOption, System.Threading.CancellationToken cancellationToken) [0x00049] in <09d4a140061c48849b6322067e841931>:0
  at System.Net.Http.HttpClient.GetAsync (System.Uri requestUri, System.Net.Http.HttpCompletionOption completionOption, System.Threading.CancellationToken cancellationToken) [0x0000c] in <09d4a140061c48849b6322067e841931>:0
  at System.Net.Http.HttpClient.GetAsync (System.Uri requestUri, System.Net.Http.HttpCompletionOption completionOption) [0x00008] in <09d4a140061c48849b6322067e841931>:0
  at System.Net.Http.HttpClient.GetAsync (System.Uri requestUri) [0x00000] in <09d4a140061c48849b6322067e841931>:0
  at System.Net.Http.HttpClient.GetAsync (System.String requestUri) [0x00008] in <09d4a140061c48849b6322067e841931>:0
  at HttpClientTest.Program.Main (System.String[] args) [0x00007] in <8019b64f4f864b30ba0f2936c90cfab0>:0

In another app (which I can't post here), I get others as well:

System.MissingFieldException: Field 'System.Net.ExceptionHelper.WebPermissionUnrestricted' not found.

System.MissingMethodException: Method 'System.Net.ServicePointManager.CloseConnectionGroups' not found.

Same results on Mono 4.8.0 or 5.0.0.

[mattjohnsonpint]

@blowdart - Could this be a side effect of #21591?

[karelz]

@marek-safar @ericstj any insight here?

[blowdart]

Shouldn't have affected it

[marek-safar]

All versions of System.Net.Http are broken on Mono because they use private API available in .NET assemblies only (bad InternalsVisibleTo). To workaround that Mono has a hack to disable loading such assemblies and use always Mono's ones. You can simply fix it by deleting System.Net.Http.dll from your bin folder or wait for Mono 5.2 with updated table of broken assemblies.

@ericstj this is again issue we reported months ago as https://github.com/dotnet/corefx/issues/15112 which you marked as fixed but the assembly does not have your fix. Could you please re-address the issue.

[ericstj]

@marek-safar the fix for https://github.com/dotnet/corefx/issues/15112 has not yet been released. That is part of the .NET Core 2.0 release. Package 4.3.2 is a servicing release for .NET Core 1.1.

[karelz]

Do we need to backport it? Or should we just wait for 2.0 to ship?

@mj1856 can you please validate it on .NET Core 2.0 Preview 1 bits? We want to confirm the problem is gone ...

[marek-safar]

I see. I had no idea .NET framework specific issue is part of .NET Core 2.0 release.

[ericstj]

It's a package related issue and the packages ship with .NET Core. I do think there is an interesting pivot here. Many of the packages which you care about do not ship in 2.0, instead we are shipping the NETStandard.Library.NETFramework package and deprecating the standalone packages.

[mattjohnsonpint]

@karelz - I tried the latest 4.4.0.preview1-25218-03 from the myget feed, and it has the same issue.

[ericstj]

@mj1856 we no longer produce this package as I mentioned above. You can use the NETStandard.Library.NETFramework package in its place.

[mattjohnsonpint]

@marek-safar - just to confirm, I deleted System.Net.Http.dll from the bin dir and indeed it runs fine. I assume because the dll is not found in the local directory it binds to a copy Mono provides?

[mattjohnsonpint]

It still gives the error when using the NETStandard.Library.NETFramework package instead of just System.Net.Http. I tried both 2.0.0-preview1-25305-02 from Nuget, and 2.0.0-preview2-25317-01 from the MyGet feed.

@marek-safar's explaination makes sense to me. Our plan is to just stay on 4.3.1 when running on Mono until Mono 5.2 ships with the updated table. Just not sure if this approach will work for others.

I have to say - I'm concerned about the "deprecating the standalone packages" bit. Pulling in NETStandard.Library.NETFramework blew up the number of .dll's in the output, including things I don't need here, like System.Drawing, etc. I liked the individual packages approach. I hope they stay. Is this being discussed on another issue somewhere?

[karelz]

@mj1856 there are downsides of many packages - e.g. VS showing you 30 of them that you depend on. So it has pros and cons.

Can someone confirm that there is reasonable path forward and decent user experience as well? I hope users don't have to delete packages, etc. when upgrading their projects. That would be pretty unfortunate.

[marek-safar]

@ericstj is there any doc how NETStandard.Library.NETFramework package is suppose to be used or migrated to? It now has PreferInbox flag but as nobody told us about new APIs there, it'll crash at runtime on Mono due to API mismatch.

[ericstj]

I believe all the APIs in there are all part of netstandard 2.0. /cc @weshaggard @davidsh

The plumbing for NETStandard.Library.NETFramework is still being worked on, coordinated by @terrajobst. The short of it is that it will be auto-referenced by NuGet when any ns2.0 package is installed to a packages.config-based project, and injected automatically by targets in any PackageReference-based target (similar to how netcoreapp and netstandard work today).