Support labels for runtime packs #11824

dsplaisted · 2020-05-30T01:33:13Z

This PR will:

Allow available runtime packs to be specified in KnownRuntimePack items, separately from KnownFrameworkReference items
Allow a set of runtime labels to be specified on a FrameworkReference via RuntimePackLabels metadata
Require that the resolved runtime pack has the same set of labels specified in the FrameworkReference
In the test framework, refactor BuildCommand and RestoreCommand so they can be used with less boilerplate code

This will allow separate runtime packs to be specified for Mono, and for projects to opt in to using the Mono runtime packs. It could also be used for other options, such as AOT policy. See dotnet/runtime#34193.

A KnownRuntimePack item has much of the same information as a KnownFrameworkReference. It can look like this:

    <KnownRuntimePack Include="Microsoft.NETCore.App"
                      TargetFramework="net5.0"
                      RuntimeFrameworkName="Microsoft.NETCore.App"
                      DefaultRuntimeFrameworkVersion="5.0.0-preview1"
                      LatestRuntimeFrameworkVersion="5.0.0-preview1.1"
                      RuntimePackNamePatterns="Microsoft.NETCore.App.Runtime.Mono.**RID**"
                      RuntimePackRuntimeIdentifiers="linux-arm;linux-arm64;linux-musl-arm64;linux-musl-x64;linux-x64;osx-x64;rhel.6-x64;tizen.4.0.0-armel;tizen.5.0.0-armel;win-arm;win-arm64;win-x64;win-x86;ios-arm64;ios-arm;ios-x64;ios-x86;tvos-arm64;tvos-x64;android-arm64;android-arm;android-x64;android-x86;browser-wasm"
                      IsTrimmable="true"
                      RuntimePackLabels="Mono"
                      />

This would be selected when the FrameworkReference has metadata that specifies RuntimePackLabels="Mono". This can be done with the following:

<FrameworkReference Update="Microsoft.NETCore.App"
                     RuntimePackLabels="Mono" />

Note that this isn't the primary method by which end-users should opt into a specific runtime pack, but rather the underlying mechanism we would use to implement user-facing properties such as UseMonoRuntime.

dsplaisted · 2020-06-01T19:13:48Z

/azp run

azure-pipelines · 2020-06-01T19:13:53Z

Pull request contains merge conflicts.

IE for .NET Standard

dsplaisted · 2020-06-17T21:43:44Z

Also related to #11227

wli3 · 2020-06-20T04:20:20Z

src/Tasks/Microsoft.NET.Build.Tasks/ProcessFrameworkReferences.cs

            public string TargetingPackFormat => _item.GetMetadata("TargetingPackFormat");

+            //public string RuntimePackNamePatterns => _item.GetMetadata("RuntimePackNamePatterns");
+


wli3 · 2020-06-20T04:20:40Z

src/Tasks/Microsoft.NET.Build.Tasks/ProcessFrameworkReferences.cs

+            public string Name => _item.ItemSpec;
+
+            ////  The framework name to write to the runtimeconfig file (and the name of the folder under dotnet/shared)
+            //public string RuntimeFrameworkName => _item.GetMetadata(MetadataKeys.RuntimeFrameworkName);


wli3 · 2020-06-20T04:35:57Z

I need this PR to be in to continue cswinrt work or I will have a really bad merge conflict. I will address my comments with cswinrt PR (or a separate PR).

sfoslund · 2020-06-24T23:37:14Z

@wli3 @dsplaisted what's the motivation for filtering out profiles like WindowsForms and WPF? It looks like this caused the bug in the SDK-> installer insertions because WindowsForms has an extra RID in its RuntimePackRuntimeIdentifiers metadata (win-arm64) that gets lost with the new logic.

If we change matchingRuntimePacks[0] to knownFrameworkReference.ToKnownRuntimePack() here it fixes things because we get WindowsForms, including the extra RID, instead of the runtime pack that only has win-x86 and win-x64. Although that essentially side steps a lot of the new logic.

dsplaisted · 2020-06-25T04:04:15Z

I need this PR to be in to continue cswinrt work or I will have a really bad merge conflict. I will address my comments with cswinrt PR (or a separate PR).

Thanks @wli3!

dsplaisted · 2020-06-25T04:10:46Z

@wli3 @dsplaisted what's the motivation for filtering out profiles like WindowsForms and WPF? It looks like this caused the bug in the SDK-> installer insertions because WindowsForms has an extra RID in its RuntimePackRuntimeIdentifiers metadata (win-arm64) that gets lost with the new logic.

If we change matchingRuntimePacks[0] to knownFrameworkReference.ToKnownRuntimePack() here it fixes things because we get WindowsForms, including the extra RID, instead of the runtime pack that only has win-x86 and win-x64. Although that essentially side steps a lot of the new logic.

@sfoslund The motivation was so that you would only have to define a runtime pack once and it would apply to all possible profiles. I think it also simplified the implementation.

I hadn't considered Windows Forms supporting different RIDs than WPF, and I'm not sure exactly what to do to fix it. I would lean towards some kind of special case fix, since I think WPF is supposed to support ARM64 eventually.

…se/2.1.6xx Merge release/2.1.5xx to release/2.1.6xx

We need this now that we changed the name of the Mono-based runtime packs. See dotnet/sdk#11824 for the design. Fixes dotnet/sdk#11227

dsplaisted force-pushed the runtime-pack-types branch from f4d83b6 to d4f7c6b Compare June 1, 2020 18:20

dsplaisted added 2 commits June 1, 2020 12:21

Add strings for runtime pack resolution failures

1850018

Add support for matching runtime packs based on labels

262fa48

dsplaisted force-pushed the runtime-pack-types branch from d4f7c6b to 262fa48 Compare June 1, 2020 19:56

dsplaisted added 2 commits June 8, 2020 18:22

Handle matching runtime packs to multiple possible framework references

c7d69c0

Fix handling runtime packs when there isn't one

2f15741

IE for .NET Standard

dsplaisted force-pushed the runtime-pack-types branch 2 times, most recently from 3158106 to 5f1cab0 Compare June 18, 2020 18:26

dsplaisted added 2 commits June 18, 2020 12:39

Simplify BuildCommand creation

66bdd23

Simplify RestoreCommand creation

96b6408

dsplaisted force-pushed the runtime-pack-types branch from 5f1cab0 to 96b6408 Compare June 18, 2020 19:40

Add tests for runtime packs with labels

eec03a6

dsplaisted marked this pull request as ready for review June 18, 2020 22:27

dsplaisted requested review from a team, sfoslund and wli3 June 19, 2020 00:37

wli3 approved these changes Jun 20, 2020

View reviewed changes

wli3 mentioned this pull request Jun 20, 2020

Clean up and refactoring ProcessFrameworkReferences #12117

Closed

wli3 merged commit 4112eb3 into dotnet:master Jun 20, 2020

This was referenced Jun 22, 2020

[master] Update dependencies from dotnet/sdk dotnet/installer#7841

Merged

[release/5.0.1xx-preview7] Update dependencies from dotnet/sdk dotnet/installer#7850

Merged

sfoslund mentioned this pull request Jun 25, 2020

Support runtime packs with differing runtime IDs #12199

Merged

rainersigwald pushed a commit that referenced this pull request Jul 20, 2020

Merge pull request #11824 from dotnet/merges/release/2.1.5xx-to-relea…

f769321

…se/2.1.6xx Merge release/2.1.5xx to release/2.1.6xx

dsplaisted mentioned this pull request Aug 20, 2020

How to handle Runtime Pack naming when targeting > 1 VM dotnet/runtime#34193

Closed

dsplaisted mentioned this pull request Oct 30, 2020

Self-contained apps can use the Mono VM (and AOT) on desktop operating systems #11227

Closed

akoeplinger mentioned this pull request Jan 28, 2021

Update host logic to support optional VM assembly dotnet/runtime#47481

Closed

akoeplinger mentioned this pull request Apr 13, 2021

Add KnownRuntimePack entries for Mono-based runtime packs dotnet/installer#10206

Merged

sbomer mentioned this pull request Jan 31, 2023

NativeAOT publish should respect updating FrameworkReference RuntimeFrameworkVersion dotnet/runtime#81382

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Support labels for runtime packs #11824

Support labels for runtime packs #11824

Uh oh!

dsplaisted commented May 30, 2020 •

edited

Loading

Uh oh!

dsplaisted commented Jun 1, 2020

Uh oh!

azure-pipelines bot commented Jun 1, 2020

Uh oh!

dsplaisted commented Jun 17, 2020

Uh oh!

wli3 Jun 20, 2020

Uh oh!

wli3 Jun 20, 2020

Uh oh!

wli3 commented Jun 20, 2020

Uh oh!

sfoslund commented Jun 24, 2020

Uh oh!

dsplaisted commented Jun 25, 2020

Uh oh!

dsplaisted commented Jun 25, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		public string TargetingPackFormat => _item.GetMetadata("TargetingPackFormat");

		//public string RuntimePackNamePatterns => _item.GetMetadata("RuntimePackNamePatterns");

Support labels for runtime packs #11824

Support labels for runtime packs #11824

Uh oh!

Conversation

dsplaisted commented May 30, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dsplaisted commented Jun 1, 2020

Uh oh!

azure-pipelines bot commented Jun 1, 2020

Uh oh!

dsplaisted commented Jun 17, 2020

Uh oh!

wli3 Jun 20, 2020

Choose a reason for hiding this comment

Uh oh!

wli3 Jun 20, 2020

Choose a reason for hiding this comment

Uh oh!

wli3 commented Jun 20, 2020

Uh oh!

sfoslund commented Jun 24, 2020

Uh oh!

dsplaisted commented Jun 25, 2020

Uh oh!

dsplaisted commented Jun 25, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

dsplaisted commented May 30, 2020 •

edited

Loading