Docs: Remove RuntimeIdentifiers guidance

[dasMulli]

<RuntimeIdentifiers> no longer has the desired effect of pre-fetching runtime-specific packages for self-contained deployments.

Since the automatic patch version roll-forward, <RuntimeIdentifiers> would for example only fetch the 2.1.0 package, but when you do dotnet publish -r RID, then the roll-forward kick in and a newer patch version will be fetched.

The <RuntimeIdentifiers> property only helps to pre-fetch RID-specific packages until the first patch version is released. Afterwards, it will only fetch unnecessary .0 patch packages for the specified runtimes and no packages that would help when executing with ´-r RID`.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 8ee36626-0fc2-20d8-81c5-a3cd212244b2
• Version Independent ID: 044ba93c-9ad9-80c7-dc5c-27a80c9bd921
• Content: .NET Core app deployment with CLI tools
• Content Source: docs/core/deploying/deploy-with-cli.md
• Product: dotnet-core
• GitHub Login: @rpetrusha
• Microsoft Alias: ronpet

[dasMulli]

@mairaw where would I open a bug because I cannot create a GH issue from the live site containing < or > without having that changed to < and > in the created GH issue? (see the first edit of the issue)

[Thraka]

@dasMulli Are you stating this information as a way to get this article updated with that? or are you saying that this is a bug and it should be pre-fetching runtime-specific packages for self-contained deployments?

I've just opened a PR on this article that rewrites the majority of it. However, I don't talk about the <runtimeplatform> nodes in the project file as on the command line you still have to specify the runtime with -r and it doesn't care what you have in the project.

[dasMulli]

I meant that the information should be removed since there is no value (longer than until the first servicing release of a major/minor version) in adding the <RuntimeIdentifiers> property to a project file.
Didn't want to open a PR since it may need some discussion.

I belive the RID should only be passed on the commandline when using multiple RIDs or use the singular <RuntimeIdentifier> in the project file (e.g. if you need to stick to win-x86 for some native library dependencies).

[Thraka]

Ok well, the rewrite doesn't mention the project setting anymore. I couldn't really figure out why it existed, though maybe visual studio uses it so that when you build, it builds out each runtime in there? But that would be a specific for the other article. I'm going to link this to the PR so the issue gets closed when the article is merged.

[dasMulli]

No it doesn't build it.

What happens is that NuGet collects your package reference and generates a graph for each restore target.

You can see them in obj/project.assets.json.
So if you have a netcoreapp2.2 you will get a { "targets": { ".NETCoreApp,Version=v2.2": { … }}} entry.
If you add runtime identifiers in the mix, NuGet will create separate graphs for each RID, so you'll additionally get a .NETCoreApp,Version=v2.2/osx-x64 for instance.

When you add the plural RuntimeIdentifiers you ask NuGet to create additional graphs for each of the specified runtimes.
Packages may have runtime-specific dependencies. So Microsoft.NETCore.App can depend on a RID-specific implementation.
So for a netcoreapp2.2 containing <RuntimeIdentifiers>osx-x64</RuntimeIdentifiers>, you'll get:

    ".NETCoreApp,Version=v2.2/osx-x64": {
      "Microsoft.NETCore.App/2.2.0": {
        "type": "package",
        "dependencies": {
          "Microsoft.NETCore.DotNetHostPolicy": "2.2.0",
          "Microsoft.NETCore.Platforms": "2.2.0",
          "Microsoft.NETCore.Targets": "2.0.0",
          "NETStandard.Library": "2.0.3",
          "runtime.osx-x64.Microsoft.NETCore.App": "2.2.0"
        },

Note the dependency on runtime.osx-x64.Microsoft.NETCore.App version 2.2.0. This is the self-contained runtime for osx-x64. During the restore, this package will be downloaded. This may be beneficial if you are publishing for this runtime since it will be on disk when publishing. Before 2.0 introduced the automatic restore during build/publish, you couldn't publish for a runtime since the graph entry and the package on disk would be missing.

But from 2.1 onwards, MSBuild logic rolls forward the patch version of the targeted package version. Basically if you're building for a specific runtime, it changes the dependency version of Microsoft.NETCore.App to the latest known patch version.
So running dotnet publish -r osx-x64 will create different inputs to NuGet and the implicit restore will change the graph to:

      "Microsoft.NETCore.App/2.2.1": {
        "type": "package",
        "dependencies": {
          "Microsoft.NETCore.DotNetHostPolicy": "2.2.1",
          "Microsoft.NETCore.Platforms": "2.2.0",
          "Microsoft.NETCore.Targets": "2.0.0",
          "NETStandard.Library": "2.0.3",
          "runtime.osx-x64.Microsoft.NETCore.App": "2.2.1"
        },

And the latest version of runtime.osx-x64.Microsoft.NETCore.App will be downloaded.

This roll-forward renders the <RuntimeIdentifiers> tag quite useless given that it was mostly used to pre-fetch self-contained packages because after the first patch release, a new restore will be necessary for the self-contained publish.

[Thraka]

Thanks for helping explain the process. I was just investing a lot of this too for that article, trying to understand everything better.

[psimoneau22]

the documentation also needs to be updated here: https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-patch-selection#how-to-avoid-restore-during-publish

[Adron]

Just read this thread after being redirected here from the docs per @psimoneau22's message that those docs need updated. After reading through this, I'm not entirely sure what needs to be changed if I'm getting the following error, which redirects to this docs page:

Error : NETSDK1061: The project was restored using Microsoft.NETCore.App version 1.0.0, but with current settings, version 2.2.3 would be used instead. To resolve this issue, make sure the same settings are used for restore and for subsequent operations such as build or publish. Typically this issue can occur if the RuntimeIdentifier property is set during build or publish but not during restore. For more information, see https://aka.ms/dotnet-runtime-patch-selection.
d:\a\1\s\CassieCoreLibTests\CassieCoreLibTests.csproj : error : NETSDK1061: The project was restored using Microsoft.NETCore.App version 1.0.0, but with current settings, version 2.2.3 would be used instead. To resolve this issue, make sure the same settings are used for restore and for subsequent operations such as build or publish. Typically this issue can occur if the RuntimeIdentifier property is set during build or publish but not during restore. For more information, see https://aka.ms/dotnet-runtime-patch-selection.
Done Building Project "d:\a\1\s\CassieCoreLibTests\CassieCoreLibTests.csproj" (default targets) -- FAILED.
Project "d:\a\1\s\CassieSchemaMigrator.sln" (1) is building "d:\a\1\s\CassieCoreLib\CassieCoreLib.csproj" (3) on node 1 (default targets).

[Thraka]

@Adron Have you tried cleaning the project and then rebuilding it? I usually see this error when the obj directory has other runtimes cached.

[dasMulli]

Microsoft.NETCore.App version 1.0.0 sounds fishy, are you setting any special properties while building?