The release of System.Reactive 4.0 breaks dotnet fake

[SteveGilham]

Description

Following the new release at ~17:00UTC Friday 25 May, builds from clean have stopped working. In each case the script fails with

-> Could not load 'System.Reactive.Linq, Version=3.0.3000.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263'.
   Full framework assemblies are not supported!
   You might try to load a legacy-script with the new netcore runner.
   Please take a look at the migration guide: https://fake.build/fake-migrate-to-fake-5.html

Repro steps

Install Fake RC 16-225, then dotnet fake run this script

#r "paket:
nuget Fake.Core.Target prerelease
nuget Fake.Core.Environment prerelease
nuget Fake.Core.Process prerelease
nuget Fake.DotNet.AssemblyInfoFile prerelease
nuget Fake.DotNet.Cli prerelease
nuget Fake.DotNet.MSBuild prerelease
nuget Fake.DotNet.NuGet prerelease
nuget Fake.DotNet.Testing.NUnit prerelease
nuget Fake.DotNet.Testing.OpenCover prerelease
nuget Fake.DotNet.Testing.XUnit2 prerelease
nuget Fake.IO.FileSystem prerelease
nuget Fake.Testing.ReportGenerator prerelease //"

open System
open System.IO
open System.Xml
open System.Xml.Linq

open Fake.Core
open Fake.Core.Target
open Fake.Core.TargetOperators
open Fake.DotNet
open Fake.DotNet.AssemblyInfoFile
open Fake.DotNet.NuGet.NuGet
open Fake.DotNet.Testing.NUnit3
open Fake.Testing
open Fake.DotNet.Testing
open Fake.IO
open Fake.IO.FileSystemOperators
open Fake.IO.Globbing.Operators
open Fake.IO.Globbing.Tools

let Target s f =
  Description s
  create s f

// Preparation

Target "Preparation" ignore

Description "ResetConsoleColours"
let resetColours = (fun _ ->
  System.Console.ResetColor()
)
createFinal "ResetConsoleColours" resetColours
activateFinal "ResetConsoleColours"

Target "All" ignore

"Preparation"
==> "All"

runOrDefault "All"

Expected behavior

Nothing much happens

Actual behavior

Script reported an error:
-> FileLoadException: Could not load file or assembly 'System.Reactive.Linq, Version=3.0.3000.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263'. General Exception (Exception from HRESULT: 0x80131500)
   StackTrace:
        at Fake.Core.TargetModule.runInternal(Boolean singleTarget, Int32 parallelJobs, String targetName, FSharpList`1 args)
        at [email protected](Boolean singleTarget, Int32 parallelJobs, FSharpList`1 arguments) in D:\a\1\s\src\app\Fake.Core.Target\Target.fs:line 819
        at Fake.Core.TargetModule.runWithDefault$cont@778-1(Boolean allowArgs, FSharpFunc`2 fDefault, FSharpMap`2 results, Unit unitVar) in D:\a\1\s\src\app\Fake.Core.Target\Target.fs:line 810
        at <StartupCode$Untitled-1_2FCFAC21BA7B45BC653F44FF9B5C2614F4ACF0473B9CBFCD2C21EE75219837AF>.$Untitled-1$fsx.main@() in C:\Users\steve\Documents\GitHub\altcover\Untitled-1.fsx:line 54
-> Could not load 'System.Reactive.Linq, Version=3.0.3000.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263'.
   Full framework assemblies are not supported!
   You might try to load a legacy-script with the new netcore runner.
   Please take a look at the migration guide: https://fake.build/fake-migrate-to-fake-5.html
   StackTrace:
        at Microsoft.FSharp.Core.PrintfModule.PrintFormatToStringThenFail@1645.Invoke(String message)
        at [email protected](AssemblyLoadContext loadContext, AssemblyName name, VerboseLevel logLevel, FSharpList`1 runtimeDependencies) in D:\a\1\s\src\app\Fake.Runtime\CoreCache.fs:line 280
        at System.Runtime.Loader.AssemblyLoadContext.ResolveUsingLoad(AssemblyName assemblyName)
        at System.Runtime.Loader.AssemblyLoadContext.Resolve(IntPtr gchManagedAssemblyLoadContext, AssemblyName assemblyName)

Known workarounds

None yet

Related information

Observed on both Windows (AppVeyor) and Linux (travis-ci)

[kblohm]

As a workaround, you could restrict System.Reactive to a use a lower version.
nuget System.Reactive ~> 3.1 works for me.

[matthid]

1. Are you not using a lockfile?
2. Wow, thanks for the report

[matthid]

Ok I did some investigations and apparently they changed their dependencies:

• 3.x -> System.Reactive depends on System.Reactive.Linq (which I think is what we use)
• 4.x -> System.Reactive.Linq depends on System.Reactive (which means we no longer get a dependency to System.Reactive.Linq)

As we depend on System.Reactive that explains the behavior. Fix is that we need to depend on System.Reactive.Linq instead

[ghuntley]

Howdy Folks. Have dinged this into the Rx team. /cc @onovotny. He wakes up in a couple hours. I'm out on a bucks night so can't dig in. Sorry to hear of breakage.

PS We hang out over at https://reactiveui.net/slack in #rxnet

[matthid]

Another workaround is to add nuget System.Reactive.Linq and nuget System.Reactive.Core in your dependencies and to delete your build.fsx.lock (if it exists)

I'm not exactly sure what's going on with System.Reactive.Core...

[matthid]

Not sure if that breaking change was indented.

[ghuntley]

I've had a few beers but....

Could not load 'System.Reactive.Linq, Version=3.0.3000.0'

Why are 3.x assemblies referenced and mixed with 4.0 assemblies?

[matthid]

@ghuntley Can you open an issue on their github as well and link back? I think this broke all fake 5 and probably some paket users.

Why are 3.x assemblies referenced and mixed with 4.0 assemblies?

Reason is that we resolve transitive dependencies to latest by default (which is the difference to nuget basically). At runtime everything will be resolved to 4.0 (so there is no mixing, it just states that Fake.Core.Target depends on 3.0 as it is already compiled), but that fails as the required dependencies are no longer available.

[matthid]

@kblohm If you have some time can you create a PR to update the dependencies accordingly (we might need that workaround release if RX team says that breakage was intended...)

[kblohm]

Fsharp,Control.Reactive specifies nuget System.Reactive ~> 3.0.
That should not lead to:

NuGet System.Reactive - 4.0 is a transitive dependency.
It is part of following dependency chains:
-> FSharp.Control.Reactive - 4.0
-> System.Reactive - 4.0

right?

[ghuntley]

Okay so it's a couple hours until New York wakes up (Oren). We deliverately merged Rx into a all in one nuget package/assembly as part of 4.0. Compatibility facades with 3.x were published.

https://github.com/dotnet/reactive/blob/master/Rx.NET/Source/src/System.Reactive/System.Reactive.csproj

[kblohm]

I do not think we depent on System.Reactive directly. So for us to use the new versions, FSharp.Control.Reactive has to update first.
IMO the problem is that FSharp.Control.Reactive specifies nuget System.Reactive ~> 3.0 but that still resolves to 4.0 for us (probably everyone that uses paket?)

[kblohm]

@matthid i will run a build with nuget System.Reactive ~> 3.0 locally. When that finishes successfully i will make a PR.

[forki]

Are you saying >= 3 or do you mean you really mean ~> ? Because twiddle wakka is not part of nuget. kblohm <[email protected]> schrieb am Sa., 26. Mai 2018, 12:01:

…

@matthid <https://github.com/matthid> i will run a build with nuget System.Reactive ~> 3.0 locally. When that finishes successfully i will make a PR. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1966 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNBqstC5Qr8O_jZ4SvyCFxaoI9rS7ks5t2SfegaJpZM4UO0F7> .

[danielcweber]

Try to hard-code the dependencies to 3.1.1 if you don't want a dependency on 4.0. If you migrate to 4.0, don't take a dependency on System.Reactive.Linq because that's just a facade package. Reference the full package instead (System.Reactive).

[matthid]

only the final package counts and my guess is it has no upper limit

[ghuntley]

Try going to 3.11 as below that version may be too old for the shims. It's best to goto 4.x tho.

[matthid]

what we want is to unbreak people ;)

[kblohm]

Isn't' ~> adding the upper bound to the nuspec? So that https://github.com/fsprojects/FSharp.Control.Reactive/blob/master/paket.dependencies#L6 would result in < 4.0? Or do i not understand that correctly?

[forki]

Yes ne fsharp.reactive package with upper bound < 4 is needed. After that we have time to upgrade that package to 4.x kblohm <[email protected]> schrieb am Sa., 26. Mai 2018, 12:15:

…

Isn't' ~> adding the upper bound to the nuspec? So that https://github.com/fsprojects/FSharp.Control.Reactive/blob/master/paket.dependencies#L6 would result in < 4.0? Or do i not understand that correctly? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1966 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNC3zgbrhhBsIAheJGOqHOmIFVG88ks5t2StUgaJpZM4UO0F7> .

[kblohm]

@forki my question is more why that does resolve to 4.0 if it is just a transitive dependency in FAKE?

[forki]

Because it's resolving to max. That's default in paket. It has pro and cons.

[SteveGilham]

@matthid

Are you not using a lockfile?

Not on the CI servers. It hadn't really been an issue before, even while keeping up with the bleeding edge of the Fake 5 pre-releases.

[matthid]

@kblohm https://www.nuget.org/packages/Fsharp.Control.Reactive it has no upper limit. There is no automatic to apply upper limits from paket.dependencies into the final package.

[matthid]

@SteveGilham Just a word of warning about your example:

• I tested your script on staging and saw that we broke this script because we introduced a create function in AssemblyInfoFile in Fixes for Assembly info updating #1959 (and as you open AssemblyInfoFile after Target, F# will assume you meant that one in L42)
• I don't really consider adding a create function to a module a breaking change if you use fake accoding to the API guidelines (which is to not open modules and use function names)
• Therefore, I decided to take the breaking change of adding RequireQualifiedAccess-Attributes to the Target, AssemblyInfoFile and Globbing.Tools modules in order to enforce the API guidelines. I know that we said to not do any breaking change in release-candidate but I hope the reasoning behind that makes it clear. I hope not too much people have written fake 5 scripts in that style.

See 9509b63

This issue is fixed by #1967 thanks to @kblohm

[SteveGilham]

The underlying script from which the example was cut down started life using v4, so has some "for historical reasons" dead-weight to it.

Automating the enforcement of style guidelines is a GOOD THING, even if it makes the fake-as-DSL somewhat more clunky.

[matthid]

The following script will now work on staging:

#r "paket:
source https://api.nuget.org/v3/index.json
source https://www.myget.org/F/fake-vsts/api/v3/index.json
nuget Fake.Core.Target prerelease
nuget Fake.Core.Environment prerelease
nuget Fake.Core.Process prerelease
nuget Fake.DotNet.AssemblyInfoFile prerelease
nuget Fake.DotNet.Cli prerelease
nuget Fake.DotNet.MSBuild prerelease
nuget Fake.DotNet.NuGet prerelease
nuget Fake.DotNet.Testing.NUnit prerelease
nuget Fake.DotNet.Testing.OpenCover prerelease
nuget Fake.DotNet.Testing.XUnit2 prerelease
nuget Fake.IO.FileSystem prerelease
nuget Fake.Testing.ReportGenerator prerelease //"

open System
open System.IO
open System.Xml
open System.Xml.Linq

open Fake.Core
open Fake.Core.TargetOperators
open Fake.DotNet
open Fake.DotNet.NuGet.NuGet
open Fake.DotNet.Testing.NUnit3
open Fake.Testing
open Fake.DotNet.Testing
open Fake.IO
open Fake.IO.FileSystemOperators
open Fake.IO.Globbing.Operators

let MyTarget s f =
  Target.description s
  Target.create s f

let Description = Target.description
  
// Preparation

MyTarget "Preparation" ignore

Description "ResetConsoleColours"
let resetColours = (fun _ ->
  System.Console.ResetColor()
)
Target.createFinal "ResetConsoleColours" resetColours
Target.activateFinal "ResetConsoleColours"

MyTarget "All" ignore

"Preparation"
==> "All"

Target.runOrDefault "All"

Release of rc017 is on the way.