Stop producing executable `fsc` and `fsi` during source-build

[dagood]

fsc and fsi target net5.0 and have output type Exe, so when building with/for a 6.0 SDK, they download Microsoft.NETCore.App.Host.linux-x64/5.0.9 as a prebuilt dependency in order to generate the framework-dependent executable (FDE):

fsharp/src/fsharp/fsc/fsc.fsproj

Lines 5 to 15 in bb7c799

	<PropertyGroup>
	<OutputType>Exe</OutputType>
	<TargetFrameworks Condition="'$(ProtoTargetFramework)' != ''">$(ProtoTargetFramework)</TargetFrameworks>
	<TargetFrameworks Condition="'$(ProtoTargetFramework)' == ''">net472;net5.0</TargetFrameworks>
	<TargetFrameworks Condition="'$(OS)' == 'Unix'">net5.0</TargetFrameworks>
	<NoWarn>$(NoWarn);44</NoWarn> <!-- Obsolete -->
	<NoWarn>$(NoWarn);75</NoWarn> <!-- InternalCommandLineOption -->
	<AllowCrossTargeting>true</AllowCrossTargeting>
	<NGenBinary>true</NGenBinary>
	<UseAppHost>true</UseAppHost>
	</PropertyGroup>

In a Microsoft-built SDK, the FDEs don't seem to be shipped, just the framework dependent assemblies:

$ find . -iname fsi*
./sdk/6.0.100-rc.2.21505.57/FSharp/fsi.deps.json
./sdk/6.0.100-rc.2.21505.57/FSharp/fsi.dll
./sdk/6.0.100-rc.2.21505.57/FSharp/fsi.runtimeconfig.json
$ find . -iname fsc*
./sdk/6.0.100-rc.2.21505.57/FSharp/fsc.runtimeconfig.json
./sdk/6.0.100-rc.2.21505.57/FSharp/fsc.dll
./sdk/6.0.100-rc.2.21505.57/FSharp/fsc.deps.json

• Is it safe to add to <UseAppHost>false</UseAppHost> to these projects during source-builds, to remove the FDE and the prebuilt?
• Can this change be made even when source-build isn't involved? Or are these FDEs used in some other scenario that's specific to the Microsoft-built output?

@brettfo

In the past, source-build would have upgraded F# to net6.0 to get around this prebuilt, but this is no longer the preferred way to go about this. (We'd rather keep TFM parity with the Microsoft build.)

---

• For Resolve "uncategorized" prebuilts for the fsharp repo for 6.0 source-build#2526
• Related, I'm asking the same thing about csi here: Remove apphost from csi for source-build to avoid prebuilt dependency on a 3.1 apphost pack roslyn#57233. (csc already has no FDE.)

[brettfo]

@KevinRansom what are your thoughts about <UseAppHost>false</UseAppHost>? I vaguely remember needing it to be true, but I don't remember why.

[dagood]

After removing the apphost from fsc/fsi in a local build, I still see this prebuilt--tracked it down to the bootstrapping builds of fsyacc, AssemblyCheck, and fslex, which also build apphosts. The bootstrapping build steps don't save binlogs, so it was harder to spot.

It looks like those apphosts might be unused (using the DLL instead), so I'll try removing them too:

fsharp/src/buildtools/buildtools.targets

Line 23 in bb7c799

<FsLexPath Condition="'$(FsLexPath)' == ''">$(ArtifactsDir)\Bootstrap\fslex\fslex.dll</FsLexPath>

[JustinGrote]

Hi, I was looking to consume fsc to use F# to construct types/cmdlets for Powershell on the fly similar to Add-Type. Is there an alternate when using the SDK now? Is there an invocation combination by add-typing the fsc.dll that works? A C# example would be sufficient

[dagood]

Hi, I was looking to consume fsc to use F# to construct types/cmdlets for Powershell on the fly similar to Add-Type. Is there an alternate when using the SDK now?

This issue doesn't (won't) change anything about the SDK content, it's just a build infrastructure change to make building .NET from source work better by avoiding building a binary that doesn't seem to make it into the SDK anyway. The 6.0 SDK contains fsc.dll. I'd recommend looking through the resources in the repo's readme and/or filing a new issue if you have a question about how to use fsc.dll--I'm not aware of any reason it would behave unexpectedly and you'll get more skilled eyes on your questions by sending it out more broadly.

[dsyme]

This was completed in #12286