The csi project targets netcoreapp3.1 and outputs an Exe, so it uses Microsoft.NETCore.App.Host.linux-x64/3.1.18:

This is a prebuilt dependency during source-build. The apphost pack contains binaries, so it isn't possible to make it available via https://github.com/dotnet/source-build-reference-packages.

I see that in the Microsoft-built SDK, csi doesn't seem to make it in, even as a framework-dependent DLL:

$ find . -iname csi*
[no output]

As a sanity check, csc does make it into the SDK as a framework-dependent assembly:

$ find . -iname csc*
./sdk/6.0.100-rc.2.21505.57/Roslyn/bincore/csc.deps.json
./sdk/6.0.100-rc.2.21505.57/Roslyn/bincore/csc.dll
./sdk/6.0.100-rc.2.21505.57/Roslyn/bincore/csc.runtimeconfig.json

csc uses <UseAppHost>false</UseAppHost>, which avoids this prebuilt:

• Is it safe to add to csi for source-build?
• Is the framework-dependent executable needed for the Microsoft build, or can we remove apphost usage altogether for csi to unify the builds?

@sharwell @jaredpar

• I initially stumbled upon this for fsi/fsc and I'll be asking them, too: Resolve "uncategorized" prebuilts for the fsharp repo for 6.0 source-build#2526. I learned that source-build is no longer going with upgrading repos to build against the newest framework during source-build as the way to remove this kind of prebuilt usage. (Which is great news for source-build maintainability.)