runtime: HttpClient 4.3.2 broken on Mono

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> 

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.

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

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…

@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

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

<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

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

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

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