We want to define some properties and a build task to help workloads understand the contents of the runtime pack.

What we need:

1. Runtime pack includes a well-known MSBuild Item that defines the names of all the components in the runtime pack.
2. Runtime pack includes a target that takes as an input an Item list of the "selected" components and produces an Item list of the filenames that should be linked:
   • for dynamic components - the list of shared libraries
   • for static components - the list of static component libs and the component stubs for the non-"selected"/"active" components.
   • the item list should include the other shared or static libs from the native folder, too, not just the components.

The key logic is in two(*) files:

• component-manifest.props - defines the available components
• component-manifest.targets - defines the task to choose the selected components

(*): The complication is that component-manifest.props is actually a collection of files - one per RID.

Packaging:

1. Each component-manifest.props will include the host RID in the metadata. So we can make multiple (one per RID) shared framework SDK packs and the workload manifest can include all their Sdk.props without conflict.
2. Make a new nuget that just has the component-manifest.targets in it that has the single target that is RID-independent. The workload will include the Sdk.targets from this nuget. The target will pick from the components for the current target only.