WebSharper 6.1.7.476: wsfsc hanging with dotnet 9 on linux

[mawifr]

dotnet build when using dotnet 9 with WebSharper 6.1.7.476 on Linux does not work.

dotnet build hangs at following WebSharper Task, never returns:
Task "WebSharperTask" /root/.nuget/packages/websharper.fsharp/6.1.7.476/build//../tools/net6.0/linux-x64/wsfsc.sh "@/tmp/tmp9lGRwi.tmp"

Downgrade to WebSharper 6.1.7.474 is no possible workaround due to #1414

Minimal example (adapted websharper template), built with dotnet build -tl:off -v detailed
https://github.com/mawifr/WsfcHangingMinimalExample

[Jooseppi12]

Hey, so after some testing there is an issue on non-windows environments with the Booster process used by the build.

To work around this, you can try using <WebSharperStandalone>True</WebSharperStandalone>, which turns of the Booster process.

[mawifr]

Hello, thank you for your answer! Adding <WebSharperStandalone>True</WebSharperStandalone> resolves the problem that wsfsc is hanging and never returning.

But seems to introduce new errors when building a solution on linux with dotnet 9 (CI/CD pipeline). Wsfsc.sh returns Error 134 or Error 135 for several projects.

The Errors look as follows (project names replaced with "xxx")

#63 7.515 /root/.nuget/packages/websharper.fsharp/6.1.7.476/build/WebSharper.FSharp.targets(50,5): error MSB6006: "wsfsc.sh" exited with code 135. [/app/xxx/xxx.fsproj]
#63 7.519   xxx -> /app/xxx/bin/Debug/net9.0/xxx.dll
#63 7.523 /root/.nuget/packages/websharper.fsharp/6.1.7.476/build/WebSharper.FSharp.targets(50,5): error MSB6006: "wsfsc.sh" exited with code 134. [/app/xxx/xxx.fsproj]
#63 7.563 /root/.nuget/packages/websharper.fsharp/6.1.7.476/build/WebSharper.FSharp.targets(50,5): error MSB6006: "wsfsc.sh" exited with code 134. [/app/xxx/xxx.fsproj]

Local build on Windows (dotnet 9) still works fine.

Could these errors be caused by the workaround?

[Jooseppi12]

@mawifr Can you give some details of these projects? What WebSharper project type they are using and what dependencies are we working with?

[mawifr]

@Jooseppi12 The problem seems to be CI/CD related. Local build with docker image mcr.microsoft.com/dotnet/sdk:9.0 works fine.
I'll get back to you after having investigated the CI/CD pipeline errors.

Thank you for your support!

[mawifr]

Closer investigation of the pipeline showed, that the errors only occur during dotnet publish -p:Version=1.0 -p:InformationalVersion=1.0 -o out -c Debug .
dotnet build also worked fine in the pipeline.

I tried publish in docker with image mcr.microsoft.com/dotnet/sdk:9.0. Fails with same errors.
I tried publish on Windows. Works fine on windows.

Next, I took a closer look at project references and removed an unneeded reference to a Utils project. (the only change in a commit)
This somehow fixed dotnet publish in the CI/CD Pipeline and in docker.

I think publish (with active project reference) worked fine with WebSharper 6.1.7.474 and dotnet 8 on linux. But not sure about that. As BinaryFormatter was deprecated(throwing) from dotnet8 sdk, I cannot test that anymore.

As build and publish on windows always worked fine, even before removal of the reference, the problem is maybe related to project references during javascript transpilation on linux? Anyways, I'm satisfied that the pipeline is working again.

I was not able to set up a working minimal example yet. I'll get back to you if the problem reoccurs.

[Jooseppi12]

That's quite interesting! I feel like it won't be actually a problem with the javascript transpilation, otherwise you should see that in the dotnet build as well. It would be interesting to check the detailed level logs and see what is passed in to wsfsc, when you have that Utils project in the references and when it's not there.