Visual Studio and Rider cannot deal with Fable projects

[vasily-kirichenko]

1. Create a hello world app as described on http://fable.io/docs/getting-started.html
2. Check it's compiled and run successfully
3. Open the folder in VS Code, VS and Rider

Results:

VS Code

Visual Studio

Rider

[alfonsogarciacaro]

For me it works in VS for Mac. We know that VS (Windows) is not ready yet for the new .fsproj. I'm not sure about Rider, is not compatible yet with dotnet SDK 2.0? Does it work if you target netstandard1.6 instead or do you still need the FSharp.NET.Sdk package?

[vasily-kirichenko]

Rider 2017.2 EAP does support .NET Core 2.0. It works on a hello world Suave project for me. The project file is as follows:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="File1.fs" />
    <Compile Include="Program.fs" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="ExtCore" Version="0.8.46" />
    <PackageReference Include="Suave" Version="2.2.1" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="2.0.0" />
  </ItemGroup>
</Project>

The Fable's on is:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="App.fs" />
  </ItemGroup>
  <Import Project="..\.paket\Paket.Restore.targets" />
</Project>

So Fable targets netstandard2.0, but Suave - netcoreapp2.0. Can it be the problem?

[vasily-kirichenko]

And the Suave project uses plain Nuget client, not Paket.

[vasily-kirichenko]

Rider editor features has started working after adding Fable.Core and Fable.Import.Browser packages via Rider's Nuget UI:

So I suspect it's a Paket issue, that is it does not manage packages the exact same way as nuget client.

However, the deamon fails to start now:

vaski@DESKTOP-12JC270 E:\github\FableApp\src
> dotnet fable yarn-start
Fable (1.2.0) daemon started on port 61225
CWD: E:\github\FableApp
cmd /C yarn run start
'yarn' is not recognized as an internal or external command,
operable program or batch file.
Closing Fable daemon...

[MangelMaxime]

The error you got with yarn mean you don't have yarn installed.

Or perhaps the console from rider don't include the right path in it.

[vasily-kirichenko]

OMG, you are right. npm-start works just fine:

[vasily-kirichenko]

So if it works in Code and VS for Mac, it must be a Rider issue, filed one here https://youtrack.jetbrains.com/issue/RIDER-9586

[alfonsogarciacaro]

We had a similar issue in VS for Mac were the auto-restore feature conflicted with Paket, so we had to tick off Automatic Restoration of packages (I filed an issue, not sure if it's fixed, pinging @nosami). For this simple project using Nuget is enough but when you start using packages containing source files (Fable.Elmish, Fable.PowerPack, etc), Paket is needed because it provides the list of packages in proper dependency order (I didn't manage to do that just with Nuget).

BTW, Fable uses now @enricosada 's Dotnet.ProjInfo library (same as FSAC) so project resolution should behave more or less the same as with other editors besides VS.

Pinging @matthid, @forki

[vasily-kirichenko]

Thanks. I think I've already hit the problem with plain nuget and Elmish:

RROR in ./src/App.fs
E:/github/FableApp/src/App.fs(11,25): (11,44) error FABLE: Cannot find replacement for Elmish.Cmd::ofMsg
 @ ./src/FableApp.fsproj 1:0-25
 @ multi (webpack)-dev-server/client?http://localhost:8080 ./src/FableApp.fsproj

[cartermp]

I'm not sure that it's a problem with Paket. In the forthcoming 15.5 build of VS + this PR all the references load without issue in the Fable-Suave-Scaffold project, including without running build.cmd (though you still need to run it to get the node dependencies for the UI).

[nosami]

@alfonsogarciacaro: No, it's still not fixed in VS for Mac, and there is no obvious solution yet :(

VS for Mac uses the NuGet library in process for package restores, not dotnet restore or msbuild /t:Restore. As I understand it, using the library is the only way to get an automatic rollback when things go wrong.

[forki]

/cc @davkean - I thought MSBuild is the correct way to do it? Am 17.09.2017 02:30 schrieb "Jason Imison" <[email protected]>:

…

@alfonsogarciacaro <https://github.com/alfonsogarciacaro>: No, it's still not fixed in VS for Mac, and there is no obvious solution yet :( VS for Mac uses the NuGet library in process for package restores, not dotnet restore or msbuild /t:Restore. As I understand it, using the library is the only way to get an automatic rollback when things go wrong. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1151 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNBPuXF5k0w10HtNu4JVETkcobDrnks5sjGgsgaJpZM4PZ0hm> .

[enricosada]

adding myself because interested.

[7sharp9]

@nosami Is that the same issue I had?

[nosami]

@7sharp9 - yes

[forki]

As I understand it, using the library is the only way to get an automatic

rollback when things go wrong. @nosami that feels so wrong. There are so many other things that we would want to do during restore. Am 17.09.2017 16:45 schrieb "Jason Imison" <[email protected]>:

…

@7sharp9 <https://github.com/7sharp9> - yes — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1151 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNCe1HrugZQW_9ppdJXRKDNCZIaDRks5sjTChgaJpZM4PZ0hm> .

[nosami]

@nosami that feels so wrong. There are so many other things that we would
want to do during restore.

Agreed /cc: @mrward

[mrward]

VS Mac has switched from using dotnet restore, to msbuild restore and then to using the NuGet api for restoring. There is also a kind of restore when you install NuGet packages. The restore on opening the solution could be switched to just use msbuild. That would fix the problem VS Mac is causing with Paket. Another problem here is that the version of NuGet that currently ships with Mono's MSBuild is old so it generates version 2 of the project.assets.json file - although that is unrelated to this particular problem caused by VS Mac.

[forki]

@mrward using the nuget lib instead of msbuild restore is fundamentally flawed design - even for vanilla nuget. It will always use the IDE bundled version instead the one that the project needs. Also things like npm will never be able to hooked into.

[forki]

/cc @auduchinok

[mrward]

@forki - This is on my TODO list to fix.

With 'vanilla NuGet' using 'msbuild restore' would result in the version shipped with Mono's MSBuild being used which is currently older that what ships with VS Mac. Although I guess this would just be a case of ensuring Mono is updated.

[forki]

@mrward that is another issue with the .NET tooling. but at least things then are consistent with command line!

[alfonsogarciacaro]

I'm not sure it'll be entirely consistent with the command line. IIRC when you call dotnet restore the MSBuild.dll packed with the proper dotnet SDK version will be invoked.