dotnet 3.1 always restores latest fsharp.core version

[theimowski]

Description

After upgrading from .net 3.0.100 to 3.1.100 it writes incorrect version of FSharp.Core to project.assets.json.
I have pinned FSharp.Core to 4.6 however it seems .net 3.1 tries to restore latest FSharp.Core 4.7

Repro steps

https://github.com/theimowski/net40_fsharp_core_3.1.2.5

Don't pay attention to repository name - initally I thought it was related to net40 and this old version of fsharp core, but found the issue is more generic

1. dotnet build

Expected behavior

FSharp.Core version 4.6 in project.assets.json

Actual behavior

FSharp.Core 4.7 in project.assets.json

Known workarounds

I originally discovered this issue for net40 framework and old version of fsharp.core: 3.1.2.5, because for this mix dotnet build failed with a "Package FSharp.Core 4.7.0 is not compatible with net40" error:

> dotnet build
Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Paket version 5.241.5
  Starting full restore process.
  Performance:
   - Disk IO: 123 milliseconds
   - Runtime: 965 milliseconds
/Users/theimowski/sandbox/paket/net40_fsharp_core_3.1.2.5/net40_fsharp_core_3.1.2.5.fsproj : error NU1202: Package FSharp.Core 4.7.0 is not compatible with net40 (.NETFramework,Version=v4.0). Package FSharp.Core 4.7.0 supports:
/Users/theimowski/sandbox/paket/net40_fsharp_core_3.1.2.5/net40_fsharp_core_3.1.2.5.fsproj : error NU1202:   - net45 (.NETFramework,Version=v4.5)
/Users/theimowski/sandbox/paket/net40_fsharp_core_3.1.2.5/net40_fsharp_core_3.1.2.5.fsproj : error NU1202:   - netstandard2.0 (.NETStandard,Version=v2.0)
  Restore failed in 242.67 ms for /Users/theimowski/sandbox/paket/net40_fsharp_core_3.1.2.5/net40_fsharp_core_3.1.2.5.fsproj.

When I did dotnet paket restore before dotnet build the restore completed succesfully, but only for this net40 + fsharp.core 3.1.2.5 mix
The version written to project.assets.json was also correct:

> dotnet paket restore
Paket version 5.241.5
Starting full restore process.
Performance:
 - Disk IO: 121 milliseconds
 - Runtime: 871 milliseconds

> dotnet build
Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 217.41 ms for /Users/theimowski/sandbox/paket/net40_fsharp_core_3.1.2.5/net40_fsharp_core_3.1.2.5.fsproj.

Not sure what's happening here - tried to compare the files created by paket in obj directory but they seem to be identical in both cases...

[forki]

confirmed this is a bug.

It looks like the following tags in the props file are ignored.

<DisableImplicitFSharpCoreReference>true</DisableImplicitFSharpCoreReference>        
<DisableImplicitSystemValueTupleReference>true</DisableImplicitSystemValueTupleReference>

if you set those manually into your fsproj then it works and it uses FSharp.Core 4.6

I tested this multiple times with older SDKs - why is it not loading this variables from obj/*.paket.props anymore!?

/cc @KevinRansom @cartermp

[forki]

ok scratch that. It's a timing issue.
It works as soon as the props file is there, but the very first build is creating the props file and that's too late. So I guess we need to move it back into paket's targets file.

[forki]

references: #3721 #3725

[forki]

Ok please retry with latest.

But keep in mind you need to nuke obj file and check that paket's targets file is already updated. So do a paket restore or something before you build.

[theimowski]

Paket 5.241.6 seems to do the job 👍

But then I'm using FAKE 5.19 to build and it's using Paket 5.241.2 that overwrites targets file with older version.
Until FAKE catches up with newer version of Paket I can workaround that with following:

dotnet paket restore // extracts targets file version 5.241.6
PAKET_SKIP_RESTORE_TARGETS=true dotnet fake build  // prevent extracting paket targets file

Unless there's a better way of doing that?

[forki]

The other way is to put the tags into the fsproj as described above.

/cc @matthid

[theimowski]

Ok cool - placing those properties in fsproj worked as well 👍
For me issue can be closed noe unless you want to keep it open

[matthid]

Unless there's a better way of doing that?

No, that's why we have that option. I'm trying hard to only ship "stable" versions of Paket with Fake and Fake will always recommend using that version. Another possible option is to use the version FAKE recommends and apply the workaround (setting those MSBuild variables) to the directory.props

[forki]

So I should push it as minor? I can do that. Give me 10min Matthias Dittrich <notifications@github.com> schrieb am Sa., 4. Jan. 2020, 16:41:

…

Unless there's a better way of doing that? No, that's why we have that option. I'm trying hard to only ship "stable" versions of Paket with Fake and Fake will always recommend using that version. Another possible option is to use the version FAKE recommends and apply the workaround (setting those MSBuild variables) to the directory.props — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3769?email_source=notifications&email_token=AAAOANB2OEIP72E53HYLWZ3Q4CU4FA5CNFSM4KCSD6R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIC2KOQ#issuecomment-570795322>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOANCGKIYYEHNWL4PYN6LQ4CU4FANCNFSM4KCSD6RQ> .

[matthid]

It doesn't matter. In any case a new fake release is required and that always takes a while, so feel free to fix when appropriate and then it will flow into fake as usual ;)

I don't feel like this is critical enough to justify rushing a release train. Several workarounds are available.