Consider collapsing libraries reference and source projects

[ViktorHofer]

Reference assemblies can be generated by roslyn via the RefOut feature. Even though the RefOut feature would handle most of the requirements, there are other ways to accomplish this.

Collapsing our ref and source projects together would help us make progress on different developer productivity asks:

• Add a Libraries.sln that contains all the source and test projects.
• Make F12 (Go to definition) work by not jumping to ref project's source code. //presumably refout only
• Potentially (not measured yet!) save costs by eliminating the additional project evaluation and project restore for the ref project. //refout only

dotnet/project-system#6069 tracks reducing project load times inside VS when using nuget msbuild resolvers, which I see as a precursor to add a Libraries.sln to the repo.

Related issues that would be fixed by this:

• Clean up ref files to more closely match GenerateReferenceSource #26187
• Facades and NotSupported assemblies are bloated with resources they don't use #28888
• Add validation / emit errors when ref configurations contain RIDs #29154

cc @ericstj @joperezr @jaredpar @safern @Anipik

Tagging subscribers to this area: @safern, @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[joperezr]

While I totally agree that this would give us a lot of benefits, it is also worth noting some of the drawbacks of this:

• How do we plan on running ApiCompat after this? Specifically how do we make sure that we don't break ApiCompat across different TFMs?
• Today we don't have coverage for breaking ApiCompat from previous releases, but this may be something we want to consider now.
• It has been said in the past from regular code reviewers in the team that having a checked-in ref helps detecting PRs that have API changes which results in different review tactics or the need to go through API Review first. How do we plan to tackle that without a checked in source?

[ViktorHofer]

In addition to what @joperezr expressed above, here are some of the concerns that @ericstj expressed around the RefOut feature:

• resources are compiled into the ref assembly
• internals aren't stripped
• typedefs from dependencies aren't resolvable (i.e. System.Runtime -> System.Private.CoreLib)
• reference for runtime specific assembly (which reference would be picked if the project multi-targets on runtimes)
• different configurations/tfms between ref and src

[ViktorHofer]

How do we plan on running ApiCompat after this? Specifically how do we make sure that we don't break ApiCompat across different TFMs?

That's TBD. Presumably the same way we do today by comparing the generated reference assembly with the source one (which might or might not be beneficial, ie refout might already guarantee that). We would still generate the reference and the source assemblies so ApiCompat would be able to compare them.

Today we don't have coverage for breaking ApiCompat from previous releases, but this may be something we want to consider now.

AFAIK we already do: https://github.com/dotnet/runtime/blob/master/src/libraries/shims/ApiCompat.proj#L102-L119.

It has been said in the past from regular code reviewers in the team that having a checked-in ref helps detecting PRs that have API changes which results in different review tactics or the need to go through API Review first. How do we plan to tackle that without a checked in source?

Agree. We could still check-in a generated reference file for such purpose.

[ViktorHofer]

Related issue: #28888 that we might want to address if we decide to use the linker to trim down produced reference assemblies.