suggestion around the transient csproj file that may break upstream and downstream fable tooling

[smoothdeveloper]

I faced this using femto Zaid-Ajaj/Femto#102 with fable 4.6 (and earlier, not a new issue):

• fable generates a .csproj
• weird things happen on dev workflow and it exits before removing
• dotnet restore is broken with bad error message
• I didn't see the .csproj and @MangelMaxime had to help me troubleshoot with extra sensory powers

In meantime the project cracker evolves significantly, I was wondering if fable-compiler could adjust the "needs a csproj", to preclude the issue or making it easier for tooling (femto in my particular case, but other things may face issues, since it breaks vanilla dotnet restore in peculiar ways) to have safety workaround to keep everything as smooth as reasonably possible, even for neophytes.

Fable/src/Fable.Cli/ProjectCracker.fs

Line 649 in 308acef

let csprojFile = projFile.Replace(".fsproj", ".csproj")

My first guess of a minimal change would be:

• name the csproj, with something between the original fsproj name, and .csproj that highlights the nature of it
• add the assembly name property to it, if needs be for sake of the hack to work
• add an xml comment in the csproj if there is none with vast english prose that is now only in the projectcracker code (so only f# hackers can really get there in terms of workflow of using the tools, it may be too much to ask from people I want to introduce fable to as alternative to vanilla js)

No pressure and also looking for what conceptually would be a better fix (I thought the csproj should be out of tree, in $tmp, but it may mean rewriting way too many filenames for this to have a chance to work).

I think it is worth it for all projects that would remain stuck on a given fable version that would embed such patch, if the overhaul of project cracker with better msbuild bits isn't impending.

This would make fable depedent tooling able to just clear up the csproj, if dotnet restore or other SDK things fail due to it, without risk of erasing a wrong csproj ever.

[MangelMaxime]

• name the csproj, with something between the original fsproj name, and .csproj that highlights the nature of it

I think it should be possible to name with the suffix .fable.csproj or .fable-temp.csproj, without having to modify too much of Fable internal code.

• add the assembly name property to it, if needs be for sake of the hack to work

Sorry, I don't understand this proposition could you please explain what you need to happen here with XML examples or something.

• add an xml comment in the csproj if there is none with vast english prose that is now only in the projectcracker code (so only f# hackers can really get there in terms of workflow of using the tools, it may be too much to ask from people I want to introduce fable to as alternative to vanilla js)

Because all fsproj files should have the line <Project Sdk="Microsoft.NET.Sdk">, you can add a comment below that line:

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
<!--
    This is a temporary file used by Fable to restore dependencies
    If you see this file in your project, you can delete it safely
-->
    <PropertyGroup>
        <TargetFramework>netstandard2.0</TargetFramework>
        <GenerateDocumentationFile>true</GenerateDocumentationFile>
    </PropertyGroup>
	...

Note: We can put the comment at the top level of the XML file because of either the XML specs or msbuild.

No pressure and also looking for what conceptually would be a better fix (I thought the csproj should be out of tree, in $tmp, but it may mean rewriting way too many filenames for this to have a chance to work).

We discussed this idea with some other Fable contributors and this is reality not possible because the user could use some .props files in its repository and so it would break because the csproj would not know about them.

I think it is worth it for all projects that would remain stuck on a given fable version that would embed such patch, if the overhaul of project cracker with better msbuild bits isn't impending.

Right now, the idea to completely remove the needs of a .csproj is indeed to rework the project cracker to use the new features of MSBuild that came with .NET 8. We are currently, exploring ideas in that direction and how to make the transition period as seamless as possible, etc.

[smoothdeveloper]

@MangelMaxime for assembly name property, I meant <AssemblyName>OriginalName</AssemblyName> if it is needed/important for the fable operation to complete in context of project cracking.

It may not even be needed as I assume no dotnet build is being performed, no assembly is ever produced, but assuming the remaining of the project would have $(AssemblyName) somewhere, the value would have changed if the tag is not present.

Just by renaming the project from myproject.csproj to myproject.fabletemp.csproj; by default $(AssemblyName) would also turn from myproject to myproject.fabletemp.

I hope this clarifies what I meant.

[MangelMaxime]

Ah ok, I see the AssemblyName is to work around the fact that changing the file name will also change the name of assembly. I don't think this is matter indeed, because Fable just use the csproj file to get the list of dependencies for the entry project I believe.