You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to define some properties and a build task to help workloads understand the contents of the runtime pack.
What we need:
Runtime pack includes a well-known MSBuild Item that defines the names of all the components in the runtime pack.
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:
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.
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.
The text was updated successfully, but these errors were encountered:
lambdageek
changed the title
Define Mono runtime components built tooling for the workloads
Define Mono runtime components build tooling for the workloads
Jun 18, 2021
We want to define some properties and a build task to help workloads understand the contents of the runtime pack.
What we need:
The key logic is in two(*) files:
component-manifest.props
- defines the available componentscomponent-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:
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 theirSdk.props
without conflict.component-manifest.targets
in it that has the single target that is RID-independent. The workload will include theSdk.targets
from this nuget. The target will pick from the components for the current target only.The text was updated successfully, but these errors were encountered: