Fable: dotnet-fable demands specific version of dotnet SDK
Description
All the dotnet projects I have so far were built using SDK version 1.0.3 and dotnet-fable 1.0.4 was happy with it. While upgrading to paket-managed dependencies I specified dotnet-fable cli version to be "1.0.*" and it broke the build with the error:
The specified framework 'Microsoft.NETCore.App', version '1.0.5' was not found.
- Check application dependencies and target a framework version installed at:
/usr/local/share/dotnet/shared/Microsoft.NETCore.App- The following versions are installed:
1.0.3
1.0.4
1.1.0
1.1.1- Alternatively, install the framework version '1.0.5'.
Apparently 1.0.6 version of dotnet-fable imposes this requirement on the SDK version. There's nothing _anywhere_ in my working directory referencing 'Microsoft.NETCore.App', version '1.0.5', no way to tell what demands it. There's no obvious way to override this either.
For the moment I locked the dotnet-fable version in the project file, but going forward and
considering there's a release of the SDK every month or so:
- is forcing the user to keep up an absolute requirement?
I have newer version of SDK, so clearly this requirement is not even backwards-compatible, meaning running multiple project on different versions is going to be DevOps nightmare.
Repro code
https://github.com/fable-elmish/sample-react-counter
Change the fsproj to use dotnet-fable version="1.0.*" and hope you have the right version of the SDK.
Expected and actual results
Expect it to build as long as F# build succeeds.
Related information
- fable-compiler version: 1.0.6
- fable-core version: n/a
- Operating system: OSX
et1975
All 3 comments
OMG, this is crazy. Welcome to the hell of netcore versioning :fire: dotnet-fable targets netcoreapp1.0. I guess the dependency on the 1.0.5 runtime just comes because I had that runtime installed in my computer when I built it, but I didn't know new patch versions weren't backwards compatible 😡
Please note the runtime and SDK versions are two different things, see here
Unfortunately I'm not sure how to prevent this, maybe @enricosada will be our saviour as always?
On another note, until Paket can manage DotNetCliToolReference items, it's recommended you pin dotnet-fable version to the Fable.Core one in paket.dependencies, as it's done in the templates.
alfonsogarciacaro
on 25 May 2017
Workaround (will send PR for fix asap):
- do
dotnet -d fable - will show some diagnostics, find the
packagedcommandspecfactory: Looking for prefercliruntime file at `C:\Users\e.sada\.nuget\packages\dotnet-fable\1.0.6\lib\netcoreapp1.0\..\..\prefercliruntime` - create that file
C:\Users\e.sada\.nuget\packages\dotnet-fable\1.0.6\lib\netcoreapp1.0\..\..\prefercliruntime(empty is ok)
Now things should work
enricosada
on 26 May 2017
As a note for posterity.
this affect users with .NET Command Line Tools (1.0.1) (try dotnet --info) using dotnet-fable version 1.0.5 or 1.0.6.
Is ok with .NET Command Line Tools (1.0.4) with any dotnet-fable version, also previous
enricosada
on 26 May 2017
Related issues
alfonsogarciacaro
·
3Comments
MangelMaxime
·
3Comments
et1975
·
3Comments
MangelMaxime
·
3Comments
alfonsogarciacaro
·
3Comments
Most helpful comment
Workaround (will send PR for fix asap):
dotnet -d fablepackagedcommandspecfactory: Looking for prefercliruntime file at `C:\Users\e.sada\.nuget\packages\dotnet-fable\1.0.6\lib\netcoreapp1.0\..\..\prefercliruntime`C:\Users\e.sada\.nuget\packages\dotnet-fable\1.0.6\lib\netcoreapp1.0\..\..\prefercliruntime(empty is ok)Now things should work