Runtime: HttpClient 4.3.2 broken on Mono

Created on 18 May 2017 · 52Comments · Source: dotnet/runtime

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.

area-System.Net.Http bug

Source

mj1856

👍11

Most helpful comment

My workaround was to add the following AfterBuild task that removes the .NET Standard .dll:

  <Target Name="AfterBuild">  
     <Delete Files="bin/$(Configuration)/System.Net.Http.dll" /> 
  </Target>

cosminstirbu on 21 Dec 2017

👍12

All 52 comments

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

mj1856 on 18 May 2017

@marek-safar @ericstj any insight here?

karelz on 18 May 2017

Shouldn't have affected it

blowdart on 18 May 2017

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.

marek-safar on 18 May 2017

@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.

ericstj on 18 May 2017

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 ...

karelz on 18 May 2017

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

marek-safar on 18 May 2017

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.

ericstj on 18 May 2017

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

mj1856 on 18 May 2017

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

ericstj on 18 May 2017

@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?

mj1856 on 18 May 2017

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?

mj1856 on 18 May 2017

@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.

karelz on 18 May 2017

@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.

marek-safar on 19 May 2017

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).

ericstj on 19 May 2017

@marek-safar @ericstj Hi guys I was wondering if you know if we have a resolution to the issue raised here? ... e.g. the missing method.

sfmoloney on 14 Jul 2017

I think two things need to happen for this to work:

mono adds all APIs that are part of netstandard2.0 (I believe this is in progress and I suspect the latest mono build will have them).
mono prefers its own copy of System.Net.Http.dll rather than the one we build and include for windows desktop apps.

@marek-safar can you comment on these? Should we open an issue in the mono repo?

ericstj on 24 Jul 2017

The resolution is described above link, manually delete the file or upgrade to recent Mono version (e.g. 5.2) which has updated hacks for broken NETStandard assemblies.

marek-safar on 24 Jul 2017

@marek-safar I think Mono 5.2 hasn't released yet?

mj1856 on 26 Jul 2017

It's available http://www.mono-project.com/download/alpha/ but still in preview

marek-safar on 26 Jul 2017

Running into this on 5.2.0 Stable (5.2.0.215) windows. Trying to confirm something works correctly with mono.

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) [0x00027] in <2b584c66184d490c9a91f80f1c75dcc0>:0
  at System.Net.Http.HttpClient.SendAsync (System.Net.Http.HttpRequestMessage request, System.Net.Http.HttpCompletionOption completionOption, System.Threading.CancellationToken cancellationToken) [0x0007a] in <2b584c66184d490c9a91f80f1c75dcc0>:0
  at System.Net.Http.HttpClient.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00000] in <2b584c66184d490c9a91f80f1c75dcc0>:0

Removing System.Net.Http.dll does not allow me to work around the problem either:

Could not load file or assembly 'System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. assembly:System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a type:<unknown type>

seanamos on 11 Sep 2017

Is there any kind of fix for this yet? I've got a console app on .NET Framework 4.7, using the latest version of Visual Studio for Mac which comes with Mono 5.2.0.224. I get this error even after deleting the System.Net.Http.dll from my bin directory.

mickbyrne on 25 Sep 2017

Still an issue with Mono version 5.4.0.199 (macOS) Console apps using NetStd2 libraries.

sushihangover on 29 Sep 2017

👍6

Also having this issue. We force our net461 application to use Mono's fallback System.Net.Http 4.0.0 from /usr/lib/mono/4.5-api by deleting the System.Net.Http that is published with the application and changing the existing record to:

<dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
</dependentAssembly>

in the .exe.config after publishing for net461 (and netstandard2.0 on the side). But this is obviously not the preferred solution. Is anyone going to fix this in Mono?

Mono version used: 5.4.0.167

smuellener on 5 Oct 2017

👍1

@smuellener could you please file a bug report at bugzilla.xamarin.com with repro for us to investigate further?

marek-safar on 5 Oct 2017

I'm currently trying to get an ASP.Net core project targeting .NET 4.7 running and I'm getting the same error with Mono 5.4.0.201

I could probably make a repro from a clean project if anyone is interested.

stefan-schweiger on 13 Oct 2017

@marek-safar I've put the smallest repro I could come up with in this repository.

Do you still need someone to open a bug report?

Basically this is the whole code:

Program.cs

```c#
public class Program
{
public static void Main(string[] args)
{
var result = new System.Net.Http.HttpClient()
.GetAsync("https://api.ipify.org/?format=json").Result;
}
}


**TestProj.csproj**
```XML
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net47</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore" Version="2.0.0" />
  </ItemGroup>
</Project>

TestProj.sln

Microsoft Visual Studio Solution File, Format Version 15.00
# Visual Studio 2017
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "TestProj", "TestProj.csproj", "{AF0CFFD9-3273-4927-81A4-EE9A29801B42}"
EndProject
Global
    GlobalSection(SolutionConfigurationPlatforms) = preSolution
        Debug|Any CPU = Debug|Any CPU
    EndGlobalSection
    GlobalSection(ProjectConfigurationPlatforms) = postSolution
        {AF0CFFD9-3273-4927-81A4-EE9A29801B42}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
        {AF0CFFD9-3273-4927-81A4-EE9A29801B42}.Debug|Any CPU.Build.0 = Debug|Any CPU
    EndGlobalSection
EndGlobal

And this is basically my system information (you can see it in more detail in my repository):

Operating System
Mac OS X 10.12.6

Visual Studio Community 2017 for Mac
Version 7.2 (build 636)
Runtime: Mono 5.4.0.201 (2017-06/71277e78f6e) (64-bit)

NuGet
Version: 4.3.1.4445

.NET Core
Runtime: /usr/local/share/dotnet/dotnet
Runtime Version: 2.0.0
SDK Version: 2.0.0

MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.4.0/lib/mono/msbuild/15.0/bin/Sdks

stefan-schweiger on 17 Oct 2017

👍2

We have the same problem.

As proposed from @marek-safar I created a bug ticket here: https://bugzilla.xamarin.com/show_bug.cgi?id=60315
I referenced this ticket and the repro project from @stefan-schweiger

RF77 on 23 Oct 2017

@stefan-schweiger @RF77 Thanks for the repro and bug report, will try to reproduce it locally

marek-safar on 23 Oct 2017

@RF77 @marek-safar is there any reason why this issue is not viewable anymore on the xamarin bugtracker?

stefan-schweiger on 30 Oct 2017

Seems to be only visible for specific users, but I've no idea why. Currently the bug is in status confirmed, but without any target milestone. I think @marek-safar has more information.

RF77 on 30 Oct 2017

@RF77 it should be visible to anyone now

marek-safar on 31 Oct 2017

Any updates on this issue? I'm seeing the missing method exception (System.Net.Logging.get_On) running unit tests against a .net standard 2 class library that uses HttpClient. This is using Mono 5.4.1.7. Any guidance would be greatly appreciated.

johndbell on 11 Dec 2017

👍6

@johndbell - I have the exact same issues. Did you find a fix for your problem?

cosminstirbu on 16 Dec 2017

Possibly, we converted our unit test project to target dot net core instead of full framework 4.6.1. That way I believe the same version of the http client component gets used.

johndbell on 16 Dec 2017

Unfortunately, if I target dot net core instead of a full framework 4.6.1 Visual Studio for Mac doesn't show my unit tests any longer so I can't run them from the IDE.

cosminstirbu on 16 Dec 2017

Urgh, it's all over the place isn't it. We use VS4M too and have noticed it not detecting unit tests when we used PackageReferences for nuget packages recently (in full framework projects) but since moving the projects to dotnet core (which still uses package references) we can actually see them, so I'm not sure why you're not. We did have to add a reference to the Microsoft.NET.Test.Sdk nuget package though. We are using NUnit. It's described here: https://github.com/nunit/docs/wiki/.NET-Core-and-.NET-Standard

johndbell on 18 Dec 2017

If anyone wants to use dotnet-mono I added a --purge-system-net-http in 0.3.3-alpha001 flag that will delete System.Net.Http.dll after build and fix the Foobar.exe.config binding redirects and try to use the GAC version.

TheAngryByrd on 19 Dec 2017

My workaround was to add the following AfterBuild task that removes the .NET Standard .dll:

  <Target Name="AfterBuild">  
     <Delete Files="bin/$(Configuration)/System.Net.Http.dll" /> 
  </Target>

cosminstirbu on 21 Dec 2017

👍12

It's super concerning that no one at Xamarin or Microsoft has provided a non-hacky workaround to this issue. Surely deleting System.Net.Http is not the final solution...

smoogipoo on 8 Jan 2018

🎉3 👍2

There is an update on the Bugzilla ticket that references one of the Xamarin guys getting on this "asap" https://bugzilla.xamarin.com/show_bug.cgi?id=60315#c7.

I am personally facing this issue on VS4M targeting Mono 5.8.0.108 using the IdentityModel library (or anything that references System.Net.Http.HttpClient)

System.MissingMethodException: Method 'System.Net.ServicePointManager.CloseConnectionGroups' not found.
  at System.Net.Http.HttpMessageHandler.Dispose () [0x00000] in <56203551693747c19246346a733913ee>:0 
  at System.Net.Http.HttpMessageInvoker.Dispose (System.Boolean disposing) [0x0001e] in <56203551693747c19246346a733913ee>:0 
  at System.Net.Http.HttpClient.Dispose (System.Boolean disposing) [0x0002c] in <56203551693747c19246346a733913ee>:0 
  at System.Net.Http.HttpMessageInvoker.Dispose () [0x00000] in <56203551693747c19246346a733913ee>:0 
  at IdentityModel.Client.DiscoveryClient.Dispose (System.Boolean disposing) [0x00012] in <aa30339bcab84e0cbc9ddb0fc5a8242a>:0 
  at IdentityModel.Client.DiscoveryClient.Dispose () [0x00000] in <aa30339bcab84e0cbc9ddb0fc5a8242a>:0 
  at IdentityModel.Client.DiscoveryClient+<GetAsync>d__1.MoveNext () [0x0009f] in <aa30339bcab84e0cbc9ddb0fc5a8242a>:0

jpmckearin on 1 Feb 2018

I changed my Nunit project to target .NET framework version 4.7.1 and that resulted in the error disappearing (ie. the correct version of HttpClient being used).

markgibaud on 27 Mar 2018

Ironically, @cosminstirbu's workaround only works for me if I replace the '/' path separators with '\' (and I'm using VS4Mac...).

knocte on 28 Mar 2018

I changed my Nunit project to target .NET framework version 4.7.1 and that resulted in the error disappearing (ie. the correct version of HttpClient being used).

@markgibaud your workaround didn't work for me. Are you using VS2017 or VS4Mac? I'm using the latter.

knocte on 28 Mar 2018

I also met this problem. but i run my code with vs on mac it run very well. but after compiled to .exe and run with mono it appear this exception:

``Unhandled Exception: System.AggregateException: One or more errors occurred. (Field not found: System.Func2 System.Net.HttpWebRequest.ResendContentFactory Due to: Could not find field in class) ---> System.MissingFieldException: Field not found: System.Func2<System.IO.Stream, System.Threading.Tasks.Task> System.Net.HttpWebRequest.ResendContentFactory Due to: Could not find field in class at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1[TResult].Start[TStateMachine] (TStateMachine& stateMachine) [0x0002c] in :0
at System.Net.Http.HttpClientHandler.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00033] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0
at System.Net.Http.HttpMessageInvoker.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00000] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0
at System.Net.Http.HttpClient.<>n__0 (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00000] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0
at System.Net.Http.HttpClient.SendAsyncWorker (System.Net.Http.HttpRequestMessage request, System.Net.Http.HttpCompletionOption completionOption, System.Threading.CancellationToken cancellationToken) [0x0005c] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0
at AutoTool.WebRequestManager.BeginRequest[Response,Request] (System.String url, Request req) [0x00127] in :0
at AutoTool.WebRequestManager.UploadFile (AutoTool.JsonPath+FilesItem file) [0x000b5] in :0
--- End of inner exception stack trace ---
at System.Threading.Tasks.Task.ThrowIfExceptional (System.Boolean includeTaskCanceledExceptions) [0x00011] in :0
at System.Threading.Tasks.Task.Wait (System.Int32 millisecondsTimeout, System.Threading.CancellationToken cancellationToken) [0x00043] in :0
at System.Threading.Tasks.Task.Wait () [0x00000] in :0
at AutoTool.Program.Main (System.String[] args) [0x00277] in :0
---> (Inner Exception #0) System.MissingFieldException: Field not found: System.Func2<System.IO.Stream, System.Threading.Tasks.Task> System.Net.HttpWebRequest.ResendContentFactory Due to: Could not find field in class at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1[TResult].Start[TStateMachine] (TStateMachine& stateMachine) [0x0002c] in :0
at System.Net.Http.HttpClientHandler.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00033] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0
at System.Net.Http.HttpMessageInvoker.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00000] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0
at System.Net.Http.HttpClient.<>n__0 (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00000] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0
at System.Net.Http.HttpClient.SendAsyncWorker (System.Net.Http.HttpRequestMessage request, System.Net.Http.HttpCompletionOption completionOption, System.Threading.CancellationToken cancellationToken) [0x0005c] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0
at AutoTool.WebRequestManager.BeginRequest[Response,Request] (System.String url, Request req) [0x00127] in :0
at AutoTool.WebRequestManager.UploadFile (AutoTool.JsonPath+FilesItem file) [0x000b5] in :0 <---

[ERROR] FATAL UNHANDLED EXCEPTION: System.AggregateException: One or more errors occurred. (Field not found: System.Func2<System.IO.Stream, System.Threading.Tasks.Task> System.Net.HttpWebRequest.ResendContentFactory Due to: Could not find field in class) ---> System.MissingFieldException: Field not found: System.Func2 System.Net.HttpWebRequest.ResendContentFactory Due to: Could not find field in class
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1[TResult].Start[TStateMachine] (TStateMachine& stateMachine) [0x0002c] in <b4d1a66727f44ba888b54966284fabb4>:0 at System.Net.Http.HttpClientHandler.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00033] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0 at System.Net.Http.HttpMessageInvoker.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00000] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0 at System.Net.Http.HttpClient.<>n__0 (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00000] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0 at System.Net.Http.HttpClient.SendAsyncWorker (System.Net.Http.HttpRequestMessage request, System.Net.Http.HttpCompletionOption completionOption, System.Threading.CancellationToken cancellationToken) [0x0005c] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0 at AutoTool.WebRequestManager.BeginRequest[Response,Request] (System.String url, Request req) [0x00127] in <cb80118d70474ef4a30ed365510b5c64>:0 at AutoTool.WebRequestManager.UploadFile (AutoTool.JsonPath+FilesItem file) [0x000b5] in <cb80118d70474ef4a30ed365510b5c64>:0 --- End of inner exception stack trace --- at System.Threading.Tasks.Task.ThrowIfExceptional (System.Boolean includeTaskCanceledExceptions) [0x00011] in <b4d1a66727f44ba888b54966284fabb4>:0 at System.Threading.Tasks.Task.Wait (System.Int32 millisecondsTimeout, System.Threading.CancellationToken cancellationToken) [0x00043] in <b4d1a66727f44ba888b54966284fabb4>:0 at System.Threading.Tasks.Task.Wait () [0x00000] in <b4d1a66727f44ba888b54966284fabb4>:0 at AutoTool.Program.Main (System.String[] args) [0x00277] in <cb80118d70474ef4a30ed365510b5c64>:0 ---> (Inner Exception #0) System.MissingFieldException: Field not found: System.Func2 System.Net.HttpWebRequest.ResendContentFactory Due to: Could not find field in class
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[TResult].Start[TStateMachine] (TStateMachine& stateMachine) [0x0002c] in :0
at System.Net.Http.HttpClientHandler.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00033] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0
at System.Net.Http.HttpMessageInvoker.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00000] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0
at System.Net.Http.HttpClient.<>n__0 (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00000] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0
at System.Net.Http.HttpClient.SendAsyncWorker (System.Net.Http.HttpRequestMessage request, System.Net.Http.HttpCompletionOption completionOption, System.Threading.CancellationToken cancellationToken) [0x0005c] in <6b8b04ed2efa45cfbebc3a7d31b3c9d4>:0
at AutoTool.WebRequestManager.BeginRequest[Response,Request] (System.String url, Request req) [0x00127] in :0
at AutoTool.WebRequestManager.UploadFile (AutoTool.JsonPath+FilesItem file) [0x000b5] in :0 <---
````

xxpniu on 11 Jul 2019

@marek-safar I don't think this issue is useful here now in the CoreFx repo. It's an old issue and the latest comments seem very specific to Mono. I recommend we move this issue to the Mono repo or just close this issue since it doesn't seem actionable on the CoreFx side. Thoughts?

cc: @stephentoub @karelz

davidsh on 5 Sep 2019

Well, it's actionable on CoreFX side by stop relying on internal framework members. On Mono we have the only workaround which does patching of every version of this published NuGet for .NET Framework but as you can expect this is not a great solution

marek-safar on 6 Sep 2019

👍1

I am confused as what exactly is wrong and what are the options. This issue is pretty confusing and going in many directions over time, which is not helping :(
@marek-safar do you know which code depends on which internal Framework members?

Latest System.Net.Http package is direct copy of Framework sources to cause as few problems with .NET Framework compat as possible. I would be hesitant to take any changes to it.
Moreover we recommend to NOT use System.Net.Http package at all if possible. Ideally, that package should have never been shipped. Unfortunately we do not have a time machine to make it happen.

So, the questions are:

Can someone please clarify what is the root-cause here?
How can we address customer pain without touching System.Net.Http source code and reshipping that package?

karelz on 6 Sep 2019

The details are in the original log. I didn't check if this property access is the only occurrence but it probably is not.

In more details

NuGet version of System.Net.Http targetting .NET Framework includes code in HttpMessageInvoker.SendAsync which calls System.Net.Logging.On property in System.dll assembly. The Logging is internal class https://github.com/microsoft/referencesource/blob/3b1eaf5203992df69de44c783a3eda37d3d4cd10/System/net/System/Net/Logging.cs#L23 so running this NuGet depends on the internal implementation of .NET Framework not just public API which is causing problems with Mono because it's compatible only on public API surface.

marek-safar on 7 Sep 2019

@marek-safar Thanks for the details.

In a perfect world, we would ship a new fixed version of this package. However, that is impossible now. The source code for the System.Net.Http NuGet package is built out of the release/2.0 branch which is now end-of-life. We no longer can even build a new System.Net.Http package out of the master branch. We no longer have the forked copy of the .NET Framework based System.Net.Http code in the master branch to build the .NET Framework targetted binary of System.Net.Http.dll.

The guidance we give developers now is to stop using the System.Net.Http NuGet package. It is not needed anymore because the System.Net.Http.dll binary already ships in the Microsoft.NETCore.App package. And for .NET Framework targeted applications, the one in the GAC is used.

We understand that some developers still use the package because it is either directly or indirectly used by the dependencies. For those cases, we have added tooling in Visual Studio to try to ignore the System.Net.Http.dll binary from that package and use the one from Microsoft.NETCore.App package or the GAC'd version on the machine. However, this solution is not perfect because for Mono based applications there is no sufficient tooling to do that redirection.

The summary is that this is not something we can fix unfortunately except by the magic of time. Over time, developers will use updated packages of things that no longer bring in the legacy and broken System.Net.Http NuGet package.

So, since this is not actionable anymore by CoreFx for this. We plan to close this issue.

davidsh on 7 Sep 2019

👍1

I think the proposal of not shipping any update to this package makes it easier for Mono to stay on top of things which is good. At the same time, it'd be helpful to mark this package as deprecated or something like that at nuget.org.

marek-safar on 8 Sep 2019

👍1

@terrajobst @ericstj Is there any way we can "mark" the NuGet package for System.Net.Http as "deprecated" or "please stop using, instead you can simply use Microsoft.NETCore.App", etc.? Can we delist the package on NuGet.org so that new applications being developed won't find it?

Or is this a "time solves all problems" kind of thing where eventually, all the upstream packages will change and stop including this package?

davidsh on 13 Sep 2019

Was this page helpful?

0 / 5 - 0 ratings