Remove apphost from csi for source-build to avoid prebuilt dependency on a 3.1 apphost pack

[dagood]

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

roslyn/src/Interactive/csi/csi.csproj

Lines 5 to 9 in 1a415d2

	<PropertyGroup>
	<OutputType>Exe</OutputType>
	<RootNamespace>CSharpInteractive</RootNamespace>
	<TargetFrameworks>netcoreapp3.1;net472</TargetFrameworks>
	</PropertyGroup>

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:

roslyn/src/Compilers/CSharp/csc/csc.csproj

Line 13 in 1a415d2

<UseAppHost>false</UseAppHost>

• 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.)

[jaredpar]

@tmat is there a reason you're aware of that we couldn't change this?

[tmat]

I think we'd want to keep building csi.exe. Can we make UseAppHost conditional on DotNetBuildFromSource?

[dagood]

I think we'd want to keep building csi.exe.

Do you have any more info about why? Whether it makes sense to exclude it from source-build depends on whether it's important for a source-build scenario.

[tmat]

So that one can run csi.exe from command line.

[dagood]

So that one can run csi.exe from command line.

• Is the only way to get csi.exe to download https://www.nuget.org/packages/Microsoft.Net.Compilers/?
  • I can only find one that targets net472, is there a netcoreapp3.1 one?
• How does one get csi (Linux/macOS apphost)?

If it's correct to say that one can only get csi/csi.exe from a NuGet package and the .NET product build never uses it, then it seems safe to exclude building it from source build conditionally. (Source-build packages aren't available to SDK users.)

I'd question the need to build csi/csi.exe for netcoreapp3.1 / Linux in the Microsoft build. If that can be removed, we can avoid a source-build-specific condition, and the Roslyn build ends up easier to maintain.

[JoeRobich]

I think we'd want to keep building csi.exe.

@tmat Since csi doesn't ship in the .NET SDK, why would we want it to be part of SourceBuild? We could always change this in the future if we wanted to ship csi as a inbox CLI tool (like fsi).

[dagood]

We could always change this in the future if we wanted to ship csi as a inbox CLI tool (like fsi).

That would actually be a problem, because the 3.1 apphost pack isn't available to source-build. csi would have to target the current target framework (net6.0 at the moment) and I don't know what requirements that would impose on the other projects and the layout of the compilers package.

(If there's some way to safely use the net6.0 apphost pack for a netcoreapp3.1 project, we could use that today as an alternative to everything discussed in this thread. Let me know if that's a thing, although I do doubt it.)

fsi actually isn't in the SDK right now either, and I have dotnet/fsharp#12282 open about getting rid of that apphost (and the fsc apphost).

[JoeRobich]

@dagood Sorry for the phrasing. It was my hand wavy way of saying we can always enable Source Build in the future and do any necessary work to make it compatible.

[tmat]

I think we'd want to keep building csi.exe.

@tmat Since csi doesn't ship in the .NET SDK, why would we want it to be part of SourceBuild? We could always change this in the future if we wanted to ship csi as a inbox CLI tool (like fsi).

I meant we want to build it in general, not necessarily in source build. We can skip the whole project in source build.