Generate runtime packs during libraries build

[steveisok]

We're currently in the process of getting tests to run against iOS and Android. As part of the libraries build, we will be constructing .app / .apk files that will contain test assemblies + the runtime. We plan relying dotnet publish as the way to produce the test apps.

In this context, dotnet publish would be responsible for creating the final apk/ipa (or app) which can be deployed to the device. This will be same flow used by .NET developers and involves multiple sub-steps for each target.

Since publishing is done from the libraries build, we need to snap a runtime pack from the artifacts produced.

What would be the best way to accomplish this? Should we move parts / all of the installer into the libraries build?

/cc @marek-safar @danmosemsft @ericstj

[ericstj]

Should we move parts / all of the installer into the libraries build?

No, we should not do that.

You don't need a runtime pack to do this. You need to be able to override the directory that the SDK resolves for a runtime-pack. Having an actual runtime-pack would be a bad thing since you'd need to build that nuget-package, then restore it, just to extract it again.

You need to make sure you can produce something that looks like the runtime pack directory. I believe we should already have something that works, either the test-host directory or the runtime directory (artifacts\bin\runtime\tfm-OS-config-arch).

To override what the SDK thinks is the runtime pack directory it looks like there are a few options:

1. $(NetCoreTargetingPackRoot) controls where the SDK finds all packs. So if we wanted to create a structure that matches C:\Program Files\dotnet\packs in the build output we could do that then have the SDK resolve from there. We could make this work if we want, it's actually not that dissimilar from what we do with testhost so that the host can find the shared framework, but I'd prefer to reuse an existing directory than create a new one. That said, maybe we could do this and then standardize on how the installer picks up the bits that make up packages (@dagood @NikolaMilosavljevic). That might be a reasonable holistic approach to doing this across the repo.

2. Set EnableTargetingPackDownload=false and then intercept @(RuntimePack) item and set PackageDirectory metadata.

3. probably others I didn't see. Source is here: https://github.com/dotnet/sdk/blob/206ec63efbad03af4c5ce30850179b4397514855/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets

@dsplaisted what is your recommendation here.

[dagood]

I'd prefer to reuse an existing directory than create a new one. That said, maybe we could do this and then standardize on how the installer picks up the bits that make up packages (@dagood @NikolaMilosavljevic). That might be a reasonable holistic approach to doing this across the repo.

This sounds a lot like the idea to use a common sharedfx layout between Libraries and Installer: #487. (I don't know any reason off the top of my head why runtime packs would be different from the sharedfx when it comes to this kind of sharing.)

[jkotas]

don't know any reason off the top of my head why runtime packs would be different from the sharedfx

Runtime packs have different directory structure. Also, runtime packs contain different set of files (with potentially different content) than shipping sharedfx.

[dagood]

don't know any reason off the top of my head why runtime packs would be different from the sharedfx [when it comes to this kind of sharing.]

Runtime packs have different directory structure. Also, runtime packs contain different set of files (with potentially different content) than shipping sharedfx.

I meant whether it can be shared.

[dagood]

I can see now how that's ambiguous. To unpack it:
I don't know any reason why we could share a sharedfx layout between Libraries and Installer, but can't share a runtime pack layout between Libraries and Installer.

[marek-safar]

@dagood are you suggesting we should change the shared framework structure to match runtime pack?

[dagood]

No. I'm hypothesizing that it makes sense to share a layout for the runtime pack between Libraries and Installer. Some supporting data is that we have analogous work tracked for the sharedfx at #487, and nobody's shot it down. That work has nothing to do with the runtime pack, but is a similar infrastructure improvement. The general theme is that the infrastructure should take advantage of the repo migration by laying out these files once, rather than laying them out once in the Libraries subset then again in the Installer subset. I'm not aware of anything contradicting the hypothesis.

[ViktorHofer]

I agree that we should cleanup creating targeting and runtime packs just once. Not necessary for 5.0, moving.

[ViktorHofer]

As this issue was tracking to generate a runtime pack as part of the libraries build, and this has been implemented since, I believe we should close this issue.

Let's follow up on future improvements to share the runtime pack generation (cc @jkoritzinsky as he is working on that) in #487.