FCS package dependency System.Collections.Immutable versions conflict

[auduchinok]

FCS NuGet package depends on System.Collections.Immutable 1.2.0 and System.Reflection.Metadata 1.4.2 while the second depends on System.Collections.Immutable 1.3.1 making dotnet build fail with warnings and errors like:

/Users/eugene/Developer/resharper-fsharp/ReSharper.FSharp/src/FSharp.Services/FSharp.Services.fsproj:
warning NU1605: Detected package downgrade: System.Collections.Immutable from 1.3.1 to 1.2.0. Reference the package directly from the project to select a different version.

/Users/eugene/Developer/resharper-fsharp/ReSharper.FSharp/src/Psi.FSharp.LanguageService/Psi.FSharp.LanguageService.csproj:
error NU1605:  JetBrains.ReSharper.Plugins.FSharp.Psi.LanguageService (>= 1.0.0) -> JetBrains.ReSharper.Plugins.FSharp.Psi (>= 1.0.0) -> JetBrains.ReSharper.Plugins.FSharp.Common (>= 1.0.0) -> JetBrains.FSharp.Compiler.Service (>= 14.0.3) -> System.Reflection.Metadata (>= 1.4.2) -> System.Collections.Immutable (>= 1.3.1)

Why do F# compiler projects need exactly 1.2.0 while it leads to versions conflict?
Is it safe to change the version to 1.3.1 across the whole repo? Should it be just FCS nuspec?

macOS 10.12.6
NET Core 2.0 SDK 2.0.0
Mono 5.2.0.215

[vasily-kirichenko]

I think it uses the same version as Roslyn does.

[dsyme]

@KevinRansom Do you know the background to this? Or can we just fix it?

[cartermp]

Not sure where Roslyn stores the version, but I did find this, which is 1.3.1: https://github.com/dotnet/roslyn/blob/a005d6883c5939705e3e9c41a80e18cece85eb20/build/Targets/Packages.props#L154

@Pilchie is this accurate? If so, we should upgrade.

[KevinRansom]

We will use the version that Roslyn uses. There is too much risk of unexpected issues within VS if we don't do that. And too many VS components to coordinate changes that we can't just drag them all up a version.

The desktop FSharp dll's run in-process with VS and so we are dependent on their current version. We have much more leeway with the coreclr, although there are still soe restrictions on how we version for that too.

So we will match the Roslyn version at all times for the desktop dll's unless we need to go with version picked for VS. One of the tasks of updating F# to a new release of Roslyn is to ensure that we are aligned with the immutable dll version.

The issue is related to the coreclr build, so I expect we can modify it . Those versions were picked a long time ago, and our needs for coreclr versions haven't really moved forward. Also we are still kind of dependent on that project.json build. But we are much closer to jettisoning that.

I can spend some time modernizing our coreclr dependencies tomorrow, if you think that would be useful. I would like to understand ... what isn't working correctly? or are we just worried about the downgrade warning?

I hope that helps,

Kevin

[Pilchie]

Yes, that should be the right version for Roslyn. @jaredpar to double check me. Also, for CoreCLR, you probably still want to use the version Roslyn uses, since it will be in the shared framework...

[jaredpar]

Yes that is the right version (and the right place to look for it)

[auduchinok]

@KevinRansom it failed during restore in some conditions for me. After repacking FCS with referencing 1.3.1 I could successfully restore the solution.
Unfortunately, I don't remember which of NuGet.exe, msbuild and dotnet restore was used when it failed, but if it's important I can reproduce.

[cartermp]

@brettfo If you have the chance, can you take a look to see if taking a dependency on 1.3.1 is fine for 15.5?

[brettfo]

Roslyn 15.5 currently uses 1.3.1, so we're good.

[auduchinok]

Fixed by #3641.