Define pattern for single-library experiments

[ericstj]

Today single library experiments that don't change the runtime/shared-framework don't have a great pattern to follow for build / test. We should decide how these should behave and create a pattern/template to follow.

[ericstj]

@safern

Why not make all experiments instead fork from dotnet/runtime -- that would simplify things infrastructure wise.

@ericstj

I think that's very undesirable for single-standalone libraries. Building the entire runtime is pretty expensive, cloning and dealing with codeflow is as well. I guess if we aren't going to create a pattern for single libraries we should keep corefxlab around for those. Thoughts @jkotas?

@jkotas

If there is enough single libraries experiments, I agree it makes sense to have a template optimized for them.

The pattern for single libraries will need maintenance independent on whether it is in runtimelab or corefxlab. I do not think we would save anything in the long-run by keeping corefxlab alive for single libraries.

Building the entire runtime is pretty expensive, cloning and dealing with codeflow is as well.

Yes and it is a problem for dotnet/runtime too where it affects a lot more people than it would affect in dotnet/runtimelab. Another option may be to just keep improving leaf-library development experience in dotnet/runtime.

I see https://github.com/dotnet/runtimelab/tree/DllImportGenerator has no CI nor build support.

I expect that the DllImportGenerator will eventually need to start adding public runtime APIs to make progress and turn into a dotnet/runtime fork.

[ericstj]

Yes and it is a problem for dotnet/runtime too where it affects a lot more people than it would affect in dotnet/runtimelab. Another option may be to just keep improving leaf-library development experience in dotnet/runtime.

We'll do this regardless. That's not actually the problem here. The workflow for building a standalone package in dotnet/runtime is already pretty good thanks to @ViktorHofer. You can clone and build the pkgproj for most packages. The problem is that we don't have plumbing for YML to do this for PR and official builds. Nor do we support such flexibility for testing. I don't think we'd ever care about doing that sort of thing in dotnet/runtime, but we would here: assuming we still agree that this is the place for such experiments.

[safern]

I think we can add specific infrastructure running tests and building against LKG runtime and ref assemblies consumed either directly from dotnet/runtime or from the SDK, and turn it on via a an MSBuild flag on that specific branch.

This wouldn't be that hard I think given that we already build and run against ref and runtime packs built locally.

[ericstj]

Fixed in #238