search

fable-compiler / Fable

F# to JavaScript, TypeScript, Python, Rust and Dart Compiler
http://fable.io/
MIT License
2.93k stars 301 forks source link

Compilation hangs when dotnet-sdk-7 is installed #3260

Closed pkese closed 1 year ago

pkese commented 2 years ago

Description

If I install dotnet-sdk-7 besides dotnet-sdk-6, the compilation hangs after analyzing project file.

I.e. on console output, with version 6 I get full output, but on version 7 the "Started Fable compilation..." never gets printed.

...
Project and references (235 source files) parsed in 3443ms

Started Fable compilation...
....

Adding global.json with sdk version set to 6.0.403 fixes the problem.

Related information

JaggerJo commented 2 years ago

Same on MacOS

(.NET 7.0.100 + Fable 3.7.20)

alfonsogarciacaro commented 2 years ago

I have seen this. I think it actually doesn't hang, just takes very long time (which is bad too). We recently changed to Buildalyzer to parse the project files, maybe updating it or changing the options helps. This issues has some info: https://github.com/daveaglick/Buildalyzer/issues/217

marcpiechura commented 2 years ago

Hey,

I've a similar issue after upgrading to VS 17.4, which also installs SDK 7. When I try to compile, I get a lot of errors like: error FSHARP: The value, namespace, type or module 'React' is not defined ...

Adding a global.json hasn't helped initially, because I installed fable as global tool and it looks like that in this case the global.json file has no affect. After switching from a global tool to a local tool, the global.json is recognized and everything works as before.

Regards.

sebfia commented 2 years ago

Upgrading my local tools to use the latest fable 4 preview version solved the problem for me, if it helps anyone...

JaggerJo commented 2 years ago

@sebfia which version exactly? Tried it yesterday without luck.

daveaglick commented 2 years ago

Upgrading my local tools to use the latest fable 4 preview version solved the problem for me, if it helps anyone...

I'd be interested in hearing more about this too. If the slowness is due to Buildalyzer (which is actually due to a full build under the hood - though it should be no longer than calling MSBuild from the CLI), then I'm curious what changed with the latest Fable version to speed things up.

MangelMaxime commented 2 years ago

Hello @marcpiechura ,

you error seems different compared to the others. Are you using beta version of any of Elmish, Feliz, Fable, Fable.React?

marcpiechura commented 2 years ago

Hey, @MangelMaxime,

nope, stable versions for everything and I hadn’t had any issues for month, so it has to be related to the .Net 7 update. Especially given that the global.json fix worked for me too after I switched to the local tool. Also I’m developing in Windows, maybe that’s why I saw the error messages and the others did not? Just a guess..

steelcityrkp commented 2 years ago

@MangelMaxime,

I ran into the exact same issue as @marcpiechura did. None of the 'open namespace or module' were actually working and nothing would compile. This began after I updated Visual Studio (which installed the .NET 7 SDK), and it was completely resolved as soon as I created the global.json pointing at .NET 6 SDK. [My Fable was already installed as a Local tool]

It's not apparent why, from the compiler errors why, but just the installation/existence of .NET 7 SDK on the system was the difference in my case as well. (I also tested this on another machine that I hadn't installed the VS Update and it had worked)

alfonsogarciacaro commented 2 years ago

Thank you everybody by your comments. This is indeed a tricky issue as it involves interaction between Fable, F# compiler, MSBuild and Dotnet SDK... and somehow seems to have fixed itself 😆 But I've also tried to improve project parsing, although I've used a heterodox approach (details in #3265). Could you please try upgrading to theta-016 and let me know if the new solution works for you? Thanks a lot for your help!

brud commented 2 years ago

@alfonsogarciacaro hi, I have the same problem. (I tried to run dotnet fable watch -o output -s --run npm run start in SAFE stack client folder)

Upgrading to theta-016 did not change anything - only the fable_modules folder is in the output folder, but not the files of my project.

alfonsogarciacaro commented 2 years ago

Thanks for reporting @brud. I just released 4.0.0-theta-017 with some fixes. Could you please give it a try (when it's available in Nuget) and let me know if it works for you? If it doesn't work, it'd be of great help if you could run Fable with --verbose option (please place it before --run) and provide the logs. Thanks and sorry for the trouble!

nilekirk commented 1 year ago

Hi @alfonsogarciacaro We still see the problem, but with a twist: compiling twice but with a dotnet fable clean in between seems to be a workaround. After the first run, files from my project are in the out put folder, but nothing I pull in via nuget. This is resolved in the second run.

Also, nothing from nuget is in project_cracked.json after the first run, but it's all there after the second run.

I'm attaching --verbose logs of the two runs (rather long file: search for START FIRST RUN and START SECOND RUN). fable-net7-problem.txt

brud commented 1 year ago

@alfonsogarciacaro upgrading to 4.0.0-theta-017 seemed to solve the problem in my case (I also had to upgrade feliz to a pre-release version, but that's not so important)

Thank you for your help! :)

nilekirk commented 1 year ago

Some more clues:

This is the content of obj folder after dotnet paket restore

VigiLyze.fsproj.net6.0.paket.resolved
VigiLyze.fsproj.NuGet.Config
VigiLyze.fsproj.paket.props
VigiLyze.fsproj.paket.references.cached
VigiLyze.fsproj.references

If I then compile the project (which fails horribly as also reported in #3267) then the content of obj is

project.nuget.cache
VigiLyze.csproj.net6.0.paket.resolved
VigiLyze.csproj.NuGet.Config
VigiLyze.csproj.paket.props
VigiLyze.csproj.paket.references.cached
VigiLyze.csproj.references
VigiLyze.fsproj.net6.0.paket.resolved
VigiLyze.fsproj.NuGet.Config
VigiLyze.fsproj.nuget.dgspec.json
VigiLyze.fsproj.nuget.g.props
VigiLyze.fsproj.nuget.g.targets
VigiLyze.fsproj.paket.props
VigiLyze.fsproj.paket.references.cached
VigiLyze.fsproj.references

The next compile (after dotnet fable clean) succeeds.

Now for the fun part:

I can also get a successful compilation the first time by renaming all the *.fsproj.* files in the obj folder after the first restore to *.csproj.*.

alfonsogarciacaro commented 1 year ago

Thank you very much for the detailed information @nilekirk! I think you're on spot, the problem seems to be that we were restoring for the .fsproj but then trying to parse the .csproj. I've change the code to make sure when .csproj is used it is restored before parsing.

At least in my tests it seems to do the trick. Can you please try with 4.0.0-theta-018 and let me know if it works for you? Thanks again for all your help to debug the issue!

pkese commented 1 year ago

4.0.0-theta-018 works perfectly.
It even feels faster than 3.x series.

nilekirk commented 1 year ago

I can confirm that 4.0.0-theta-018 works perfectly for me. Thank you @alfonsogarciacaro!

alfonsogarciacaro commented 1 year ago

Thanks a lot for confirming @pkese @nilekirk! Ok, let's close this for now and reopen if someone else is still having issues.

Yes, it should be faster now :) The reason is for C# projects Buildalyzer does a design time build. I'm not entirely sure what's happening with F# project but it seems to be something very close to a full build which can take long time for big projects.