WinHttpHandler is only supported on .NET Framework and .NET Core runtimes on Windows in v2 function

[JohnReeson]

Repro steps

Locally create a v2 function httptrigger (host version 2.0.11857), install System.Net.Http.WinHttpHandler package and new a WinHttpHandler object, WinHttpHandler handler = new WinHttpHandler();

Expected behavior

Works without error

Actual behavior

System.Private.CoreLib: Exception while executing function: TestWinHttpHandler. System.Net.Http.WinHttpHandler: WinHttpHandler is only supported on .NET Framework and .NET Core runtimes on Windows. It is not supported for Windows Store Applications (UWP) or Unix platforms.

Known workarounds

V1 works.

[mathewc]

You are running on Windows, correct? (Not Linux). Can you also try validating against the latest bits? We've made a lot of enhancements since then.

[JohnReeson]

Yes, on Windows and also test in host 2.0.11888, same error.

[AdrianPell]

Any update on this issue? I've just run into it (using Google Ads API), and before I try to roll back to using Functions V1 - which is going to be painful reference-wise - I'd like to see if there's any workaround.

Apparently, switching Functions v2 to target .NET Core 2.1 doesn't help either :-(

[AdrianPell]

As a workaround, it's possible to put a local copy of the appropriate System.Net.Http.WinHttpHandler.dll file in the functions directory, and add the following to the csproj file:

  <ItemGroup>
    <None Update="System.Net.Http.WinHttpHandler.dll">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </None>
  </ItemGroup>
  <Target Name="CopySPSM" BeforeTargets="Build">
    <Copy SourceFiles="System.Net.Http.WinHttpHandler.dll" DestinationFolder="$(OutputPath)\bin" />
  </Target>

[JohnReeson]

@AdrianPell Thanks, the workaround works. Close it and link another one tracked.

[andrei-m-code]

@AdrianPell @JohnReeson which one is "appropriate"? I am having exactly the same issue and I need this workaround to work. Where can I find the DLL that will work?

UPD: I just took the .NET Standard one and used the workaround above and it worked. It's weird.. Looks like function runtime for some reason uses incorrect nuget package assembly platform.

[AdrianPell]

@andrei-m-code Yes, the .NET Standard one would most likely be what you needed (assuming your project is targeting that of course). See @fabiocav comments here #3568 for more color on what's actually happening.