Move host components out of installer into a common location

[ViktorHofer]

To my knowledge the host components consist of the native source files, nuget packages, the managed HostModel library and tests. Most of these assets are located under src/installer as that's where they lived before repository consolidation (core-setup repo). I propose moving these components together to common place out of src/installer:

src/host
  - Microsoft.NET.HostModel
  - native (+ msbuild entrypoint: corehost.proj)
  - packages
  - tests
  - Solution File (for opening inside VS)

As the HostModel library isn't publicly shipping but maintains the contract with the host, it doesn't belong into libraries as that's where we ship public APIs from. Aside from that, the host tests require the HostModel library and the HostModel tests aren't unit tests but end-to-end tests which we currently don't have under src/libraries.

I don't propose to change any of the subset names or the host dependencies (i.e. shared framework packs for testing).

cc @agocke @vitek-karas @VSadov @jkotas

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

---

To my knowledge the host components consist of the native source files, nuget packages, the managed HostModel library and tests. Most of these assets are located under src/installer as that's where they lived before repository consolidation (core-setup repo). I propose moving these components together to common place out of src/installer:

src/host
  - Microsoft.NET.HostModel
  - native (+ msbuild entrypoint: corehost.proj)
  - packages
  - tests
  - Solution File (for opening inside VS)

As the HostModel library isn't publicly shipping but maintains the contract with the host, it doesn't belong into libraries as that's where we ship public APIs from. Aside from that, the host tests require the HostModel library and the HostModel tests aren't unit tests but end-to-end tests which we currently don't have under src/libraries.

I don't propose to change any of the subset names or the host dependencies (i.e. shared framework packs for testing).

cc @agocke @vitek-karas @VSadov @jkotas

Author:	ViktorHofer
Assignees:	-
Labels:	Discussion, area-Infrastructure
Milestone:	-

[ViktorHofer]

Any concerns with the proposal? If not I would start decoupling the components from the src/installer infrastructure and move bits by bits.

[jkoritzinsky]

The proposal sounds good to me.

[VSadov]

The native part has been moved recently to src\native\corehost, since it is a shared component. It is used by Mono too and the singlefile part is used by clr partition build. I think that is where it should be.

The rest looks reasonable, but I wonder how much will stay under src\installer

[jkoritzinsky]

The eventual goal is to remove src/installer and have the subfolders under src better match the subset category names (host, packs).

[VSadov]

Yes, that is what I thought. Once host and packs are out, I do not think there is something that belongs to "installer".

[jkoritzinsky]

Technically, we could keep the dotnet-host.proj, dotnet-hostfxr.proj , the dotnet-runtime-prereqs folder and the bundle project in src/installer since they only build installers. Depends on what we want to do.

[ViktorHofer]

Once host and packs are out, I do not think there is something that belongs to "installer".

Absolutely. That's tracked via #49428.

Technically, we could keep the dotnet-host.proj, dotnet-hostfxr.proj , the dotnet-runtime-prereqs folder and the bundle project in src/installer since they only build installers. Depends on what we want to do.

That discussion probably belongs into #49426. I would be fine to keep it as-is (installers as part of packs) for simplicity.

The native part has been moved recently to src\native\corehost, since it is a shared component. It is used by Mono too and the singlefile part is used by clr partition build. I think that is where it should be.

We usually group sources in dotnet/runtime by component and less by language (i.e. src/libraries/*, coreclr, mono, tasks). The existing src\native\corehost folder would be renamed to src\host\native which wouldn't prevent it from being a shared component, nor indicate that these files aren't shared components. Thoughts?

[jkotas]

We usually group sources in dotnet/runtime by component and less by language

We do not have one unifying scheme how to group sources together. It is not unusual to see sources grouped by language - src/libraries/native is example of such grouping. Or to group shared or common sources used from more than one place - src/libraries/Common, src/coreclr/tools/Common or src/native are examples of such groupings.

The existing src\native\corehost folder would be renamed to src\host\native which wouldn't prevent it from being a shared component

I agree that it would not hurt, but I do not see it helping much either.

[ViktorHofer]

We do not have one unifying scheme how to group sources together. It is not unusual to see sources grouped by language - src/libraries/native is example of such grouping. Or to group shared or common sources used from more than one place - src/libraries/Common, src/coreclr/tools/Common or src/native are examples of such groupings.

Putting the first time contributor hat on I would say it's highly confusing that a "src/native" folder exists. It suggests that it contains the native source files of the repository even though it only contains a very limited set of it. Even though we might not be consistent today doesn't mean we shouldn't strive towards a consistent scheme.

src/libraries/native

The native folder under libraries actually made perfect sense as it was the home of all native code in CoreFx before repositories were consolidated. IMO it doesn't make much sense anymore in it's current form.

Or to group shared or common sources used from more than one place - src/libraries/Common, src/coreclr/tools/Common or src/native are examples of such groupings.

Absolutely agree on the necessity of shared source folders. The first two examples make perfect sense as their paths clearly indicate which component their shared sources belong.