Latest package version is compiled with .NET Core-based String.split overload making it incompatible with .NET Framework and .NET Standard 2.0

[cartermp]

Howdy @haf and friends, we got this report: dotnet/fsharp#10658

We investigated the issue thinking there may have been a bug in F# Interactive and #r "nuget:..." directives, since the user was reporting a runtime error with the following code:

#r "nuget: Hopac"
#r "nuget: Http.fs"

open Hopac
open HttpFs.Client

let url = "https://www.microsoft.com"

let response =
    Request.createUrl Get url
    |> Request.responseAsString
    |> run

The issue manifests in Visual Studio FSI since it runs as a .NET Framework 4.7.2 process right now. At runtime, it appears that Http.fs is compiled against the following String.Split overload: https://docs.microsoft.com/en-us/dotnet/api/system.string.split?view=net-5.0#System_String_Split_System_Char_System_StringSplitOptions_

However, this overload is not available in .NET Framework or .NET Standard 2.0.

We were able to verify that despite being packaged for .NET Standard 2.0 and .NET Framework, the latest version of Http.fs on NuGet is actually compiled with this String.Split overload.

This is likely due to building the library against a .NET Core 3.0+ or .NET 5 SDK that includes these overloads, since the code in question uses type inference.

However, this shouldn't happen as far as I can tell because the project already specifies that it builds against .NET Standard 2.0 and .NET Framework 4.7.2. So right now it's unclear if the issue lies in something related to packaging or if there is some weird quirk in the compiler that was used to package it.

[haf]

Strange. I don’t see how we could possibly have built against something that is not used in the fsproj (auto corrects to raptor 🦖)? But since we don’t use ifdefs, shouldn’t both compile targets use the same overload?

[cartermp]

Yeah, there's something awfully peculiar going on here. It may actually be a subtle F# compiler bug. For some reason, the F# compiler normally wraps a char in a char array (why? no idea...) but that doesn't appear to be happening in this circumstance, leading to an overload that exists and works just fine on .NET Core (and .NET Standard 2.1) but not .NET Framework or .NET Standard 2.0.

So for now it's not 100% clear where the issue lies, but I figured I'd have it tracked in both places until there's some kind of resolution.

[haf]

@cartermp Makes sense. We could recompile with a newer compiler if that would fix it.

[cartermp]

We'll see if this gets any more hits. We couldn't immediately find anything obviously wrong with the compiler (aside from pre-existing weird behavior that changing would imply a breaking change). My guess is that this isn't a terribly common issue now that so many people have moved their F# code to .NET Core, especially when doing any web or networking stuff. And on .NET Core, this doesn't manifest.

[erlis]

I'm having this exact same issue, looks like I'm one of those that haven't migrated the project to .NET Core :(

[erlis]

FYI, I downgraded to version 5.3.0 and it's working with that version!