MSBUILD : error MSB1011: Specify which project or solution file to use because this folder contains more than one project or solution file.

[lcg-gauthier-segay]

I'm running femto 0.19.0 with

$ dotnet femto src\client

and it gives:

[20:42:18 INF] Analyzing project ./src/client/client.fsproj
[20:42:18 INF] Running dotnet restore against the project
[20:42:18 ERR] dotnet restore Failed with error MSBUILD : error MSB1011: Specify which project or solution file to use because this folder contains more than one project or solution file.

Here is the folder structure:

$ dir /b/s *.fsproj
.\src\client\client.fsproj
.\src\server\server.fsproj
.\thirdparty\fable-recharts\fable-recharts.fsproj
.\thirdparty\Feliz.Plotly\Feliz.Plotly.fsproj
$ dir /b/s *.sln
.\dashboard.sln

I'm not sure if there is anything wrong in my environment:

C:\work\dashboard>dotnet --info
.NET SDK:
 Version:           8.0.100
 Commit:            57efcf1350
 Workload version:  8.0.100-manifests.71b9f198

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\8.0.100\

In anycase, it is the same error if I just do dotnet restore src\client but if I do it on the solution, it works; while if I try to run femto on the .sln:

[20:47:01 INF] Analyzing project .\dashboard.sln
[20:47:01 INF] Running dotnet restore against the project
[20:47:03 ERR] Error while analyzing the project's structure and dependencies

Here I think the diagnostic is specific to femto but there is nothing actionable I can do to troubleshoot.

[MangelMaxime]

Hello @lcg-gauthier-segay,

can you please check if you have any .csproj in your repository?

If not, would it be possible to have a reproduction repository to look at ?

[lcg-gauthier-segay]

@MangelMaxime there is none, but I notice while using fable, that it creates intermitent csproj files somehow during the compile/watch cycle. Maybe this could be the reason?

I also faced the same dotnet restore issue in FSharp.Data.SqlClient solution itself, and a lot of online discussion about the same, so it really seem to be a dotnet issue.

Is there something we could do in femto itself, to report the whole stack trace / more diagnsotic, for

Error while analyzing the project's structure and dependencies

I'll try to pay a look over the weekend in debugger.

Thanks!

[lcg-gauthier-segay]

I confirm that the spurious .csproj that fable generate was the cause!

Any idea why fable uses a transient csproj? it kind of clashes with dotnet restore in weird ways.

[MangelMaxime]

Fable generates a .csproj in order to get the dependencies list because when extracting them from .fsproj they are incomplete.

However, the .csproj file should only exist for a few seconds has Fable delete it once it get the dependencies restored. So it should not impact Femto or others tools as they don't invoke Fable.

Recently, I found in some of my project a .csproj likely generated by Fable. Perhaps, the clean up is broken will need to investigate more.

In your situation, if you remove the .csproj then all should be fine for Femto. A way to fix for ever in Femto would be check if it can specify the project file instead of just the folder.

For example, dotnet restore src/MyProject.fsproj vs dotnet restore src. The first one will works even if there is a csproj nearby

[smoothdeveloper]

Thanks @MangelMaxime, very comprehensive.

Do you think fable could somehow generate the .csproj in $TMP, by reassigning the file and references? or maybe we need to mark the .csproj as .fabletemp.csproj, so other tooling can clear it if the file isn't locked.

Should the issue about "reference being incomplete" be reported on dotnet/fsharp?

I'll close the issue, it can be reopened if people face it as well, and when I have ability, I'll look at femto and fable logic related to this issue.

[Zaid-Ajaj]

In anycase, it is the same error if I just do dotnet restore src\client

@lcg-gauthier-segay That is what Femto does internally too, I suggest using the specifying the full path of the project:

dotnet femto ./src/client/client.fsproj

It seems that maybe Femto should use a specific project to restore rather than running dotnet restore against the containing directory 🤔 I need to double check what we are doing here

[lcg-gauthier-segay]

@Zaid-Ajaj I believe it is good to enable just passing the directory name.

On the other hand, if there are no support for .sln, or femto ends up not doing anything, reporting what project and sln files are under the tree (or a summary) may prove useful to the user, before returning.

Right now, when I point to folder with .sln, it doesn't seem to be explicit that it doesn't handle .sln, it could guide the user:

found myfancyapp.sln, but no .fsproj in the given folder, femto doesn't support .sln, please pass a folder name containing a .fsproj 4 .fsproj found under the given directory

• given-dir/subdir1/subdir1.fsproj
• given-dir/subdir2....
• ....

• you may call femto on any of those folders above.

[MangelMaxime]

Should the issue about "reference being incomplete" be reported on dotnet/fsharp?

This is not really related to dotnet/fsharp but MSBuild and which properties should be passed / option activated to get a design time resolution of the dependencies.

There is currently some reflexion in Fable team to restructure how Fable works and benefit from .NET 8 MSBuild which allows to retrieve this information much more easily now. However, it will takes some time to land as this is currently deeply integrated in Fable code and also it would require people to run Fable using .NET 8 SDK so not supporting running from a lower SDKs.

[MangelMaxime]

Do you think fable could somehow generate the .csproj in $TMP, by reassigning the file and references? or maybe we need to mark the .csproj as .fabletemp.csproj, so other tooling can clear it if the file isn't locked.

This is something I though about but I don't know how feasable / easy it is. IHMO, we will probably focus on using existing solutions like .NET 8 MSBuild for such things to avoid having to hack to much around and benefit from the work done by Microsoft teams to focus on Fable internals itself.

[smoothdeveloper]

.NET 8 MSBuild which allows to retrieve this information

Seen the efforts around this from afar, it indeed looks great for tools like fable & femto.

.NET 8 MSBuild for such things to avoid having to hack to much around and benefit from the work done by Microsoft teams to focus on Fable internals itself.

Sensible, although I suggest, for the csproj, to have a file name that shows "fable necessary hack" nature of why this file exists, and a comment (not checked if there is any), just so it is not black box from end user perspective, in case the assumption breaks (fable leaving it as trail, and this breaking dotnet restore):

https://github.com/fable-compiler/Fable/blob/308aceff8602cfb0f6242c7fa2e85acd29413506/src/Fable.Cli/ProjectCracker.fs#L649

It may be a little effort compared to the overhaul.

I also believe we should have issue on dotnet/sdk that explains how dotnet restore does a "not stellar" job in helping user figuring which project, and what could be the cause for it to restore in first place, probably out of having to handle lots of msbuild magic and error messages in dotnet being what they are for now.

If the situation remains, and fable adjusted extension for transient csproj, we can document it in femto FAQ and adjust it to cleanup, as it will still occur for people using old fable and old sdk, even if we update the world for projects that keep closer to latest releases of all.

[smoothdeveloper]

tracking in https://github.com/fable-compiler/Fable/issues/3634 for now, I'll try to reproduce it for dotnet/sdk next week.

Thanks again all.