Add --use-current-runtime option #14093

am11 · 2020-10-10T16:43:16Z

It is a common use-case to use the same runtime during the build and publish. During the development of .NET apps, it is painful to remember the entire - ever growing - --runtime <baseos>-<arch> matrix.

--use-current-runtime, backed by MSBuild property UseCurrentRuntimeIdentifier=True/False, will allow users to keep things neutral in their documentation and deployment scripts.

Fixes #10449
cc @eerhardt @tmds, @dagood

dagood · 2020-10-12T18:30:08Z

It has been just over a year since the last comment on #10449, so perhaps worth double checking that this is still valid in 6.0, but it does seem useful to me.

I think @wli3 and @dsplaisted would be the best reviewers for this PR.

dsplaisted

Thanks for this!

I would prefer calling the switch something like --use-current-runtime over --infer-runtime. @KathleenDollard, thoughts?
I would also prefer having this implemented in MSBuild logic. IE setting UseCurrentRuntimeIdentifier to true would set the RuntimeIdentifier property to the current RID (possibly via the NETCoreSdkRuntimeIdentifier property). Then the --use-current-runtme command-line option would set UseCurrentRuntimeIdentifier to true, but the property could also be used outside of the dotnet command line.

am11 · 2020-10-12T22:39:45Z

@dsplaisted, thanks. I have updated the PR with --use-current-runtime and UseCurrentRuntimeIdentifier changes.

src/Cli/dotnet/commands/dotnet-restore/RestoreCommandParser.cs

dsplaisted

Sorry for the piecemeal feedback, but thanks again for your contribution.

src/Tests/Microsoft.NET.Publish.Tests/RuntimeIdentifiersTests.cs

dsplaisted · 2020-10-14T06:23:06Z

src/Cli/dotnet/commands/dotnet-restore/LocalizableStrings.resx

@@ -141,6 +141,9 @@
  <data name="CmdRuntimeOptionDescription" xml:space="preserve">
    <value>The target runtime to restore packages for.</value>
  </data>
+  <data name="CmdCurrentRuntimeOptionDescription" xml:space="preserve">
+    <value>Use host runtime to build the target.</value>


Suggested change

<value>Use host runtime to build the target.</value>

<value>Use current runtime as the target runtime.</value>

@KathleenDollard Any further suggestions for this text?

Updated in all resx/xlf files. More feedback from @KathleenDollard is welcome. :)

eerhardt · 2020-10-14T12:23:30Z

possibly via the NETCoreSdkRuntimeIdentifier property

One thing to be aware of here is that NETCoreSdkRuntimeIdentifier will be the "portable" RIDs like:

win-x64
linux-x64
osx-x64

Is that what we want for --use-current-runtime? Or do we want to use the actual machine's RID?

win10-x64
ubuntu.18.04-x64
osx.14-x64

cc @ericstj @janvorli @tmds

janvorli · 2020-10-14T12:26:51Z

@eerhardt I would prefer the portable rids. That's what I pass in to dotnet publish all of the time.

dagood · 2020-10-14T14:15:59Z

For source-build, the actual/non-portable RID would make sense here. This lets source-build users use the built-from-source Microsoft.NETCore.App.Host.<non-portable-rid> rather than downloading the portable one from nuget.org as a prebuilt. (Also, once the SDK supports bundling a runtime pack (#14044), they can do the same there (dotnet/source-build#1215).)

Either option would make sense to me as the meaning of the flag as it's currently named. I think the ambiguity might be a problem in itself. 🤔

+cc @omajid

dagood · 2020-10-14T14:28:02Z

NETCoreSdkRuntimeIdentifier

In source-build this is actually the non-portable RID, because the SDK is built for a non-portable runtime.

For source-build, either portable or non-portable might be desired. Someone could intentionally download the portable runtime/apphost packs to build an app that will run portable. But it's interesting that the behavior of this PR as-is depends on whether the SDK is built portable or non-portable.

am11 · 2020-10-14T14:28:06Z

Personally, my main use-case was to simplify deployment scripts and instructions (e.g. https://github.com/nst/JSONTestSuite/blob/master/parsers/test_dotnet_system_text_json/README.md), where portable RID would suffice.
However, I agree that non-portable RID has its merits, especially for distro providers in Linux (as well as in illumos) world(s).

An idea: why not both? 😎
e.g.
--use-current-runtime, UseCurrentRuntimeIdentifier for portable RID.
--use-current-machine-runtime, UseCurrentMachineRuntimeIdentifier for non-portable RID.

tmds · 2020-10-14T14:51:37Z

--use-current-runtime, UseCurrentRuntimeIdentifier for portable RID.

portable rid would be a meaningful default when publishing a single file.
Maybe we need a flag for single file publish?

dotnet publish --single-file

--use-current-machine-runtime, UseCurrentMachineRuntimeIdentifier for non-portable RID.

This doesn't work yet. source-build doesn't produce the artifacts to do a single-file publish for the machine rid.

am11 · 2020-10-14T14:59:45Z

--single-file is a separate concern. There are other cases and form factors (more coming up in the future, hint: superhost) where --runtime is required. Current single-file argument is -p:PublishSingleFile=true (from docs).

tmds · 2020-10-14T15:20:25Z

I meant that maybe we can use portable rid as the default for PublishSingleFile, then we don't need to add a flag and come up with a name.

am11 · 2020-10-14T15:38:00Z

IMO, explicit option is better, as it is also used for restore and other commands (beyond publish). UseCurrentRuntimeIdentifier could be later added to dotnet-new template https://github.com/dotnet/templating.

dsplaisted · 2020-10-14T17:01:57Z

Personally, my main use-case was to simplify deployment scripts and instructions (e.g. https://github.com/nst/JSONTestSuite/blob/master/parsers/test_dotnet_system_text_json/README.md), where portable RID would suffice.
However, I agree that non-portable RID has its merits, especially for distro providers in Linux (as well as in illumos) world(s).

An idea: why not both? 😎
e.g.
--use-current-runtime, UseCurrentRuntimeIdentifier for portable RID.
--use-current-machine-runtime, UseCurrentMachineRuntimeIdentifier for non-portable RID.

We need to set the RuntimeIdentifier during MSBuild evaluation. So we can't call into an arbitrary API to get the current, most-specific machine RID. So I'm not sure we have a good way to implement UseCurrentMachineRuntimeIdentifier as an MSBuild property. We might have to have it as a CLI command-line option only.

UseCurrentRuntimeIdentifier works because we have access to the "SDK" RID via the NETCoreSdkRuntimeIdentifier property which is set in Microsoft.NETCoreSdk.BundledVersions.props.

am11 · 2020-10-14T17:15:45Z

We need to set the RuntimeIdentifier during MSBuild evaluation. So we can't call into an arbitrary API to get the current, most-specific machine RID. So I'm not sure we have a good way to implement UseCurrentMachineRuntimeIdentifier as an MSBuild property. We might have to have it as a CLI command-line option only.

If running a pre-evaluation custom task is an option, we could do something like:

using System;
using System.Runtime.InteropServices;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;

public class UseCurrentMachineRuntimeIdentifierTask : Task
{
    public override bool Execute() => true;

    [Output]
    public string Value => RuntimeInformation.RuntimeIdentifier;
}

<UseCurrentMachineRuntimeIdentifierTask>
  <Output TaskParameter="Value" PropertyName="UseCurrentMachineRuntimeIdentifier"/>
</UseCurrentMachineRuntimeIdentifierTask>

dsplaisted · 2020-10-14T17:18:02Z

If running a pre-evaluation custom task is an option

It's not possible. We would have to add something to MSBuild itself (ie a new intrinsic function).

eerhardt · 2020-10-14T17:39:40Z

We would have to add something to MSBuild itself (ie a new intrinsic function).

MSBuild allows for calls to RuntimeInformation directly. I've been using that feature to call RuntimeInformation.RuntimeIdentifier in other places. See

https://github.com/dotnet/installer/blob/efe7c8e566c4c06411d028d8d565cb5f6ef7c3e4/src/redist/targets/GetRuntimeInformation.targets#L4-L5

      <HostRid Condition="'$(HostRid)' == '' and '$(MSBuildRuntimeType)' == 'core'">$([System.Runtime.InteropServices.RuntimeInformation]::RuntimeIdentifier)</HostRid>
      <HostRid Condition="'$(HostRid)' == '' and '$(MSBuildRuntimeType)' != 'core'">win-$([System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture.ToString().ToLowerInvariant)</HostRid>

Note that RuntimeInformation.RuntimeIdentifier only works on .NET 5 and not .NET Framework. So that's why the above checks $(MSBuildRuntimeType) == core.

tmds · 2020-10-22T06:33:31Z

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.RuntimeIdentifierInference.targets

                            '$(OS)' == 'Windows_NT' and
                            '$(RuntimeIdentifier)' == ''">
    <_UsingDefaultRuntimeIdentifier>true</_UsingDefaultRuntimeIdentifier>
    <RuntimeIdentifier Condition="'$(PlatformTarget)' == 'x64'">win7-x64</RuntimeIdentifier>
    <RuntimeIdentifier Condition="'$(PlatformTarget)' == 'x86' or '$(PlatformTarget)' == ''">win7-x86</RuntimeIdentifier>
  </PropertyGroup>

+  <PropertyGroup Condition="'$(UseCurrentRuntimeIdentifier)' == 'true'">
+    <RuntimeIdentifier>$(NETCoreSdkRuntimeIdentifier)</RuntimeIdentifier>


@am11 @dsplaisted @eerhardt

On a Microsoft SDK, UseCurrentRuntimeIdentifier is the same as portable rid. So --use-current-runtime means publish portable.
On a source-build SDK, this is the same as the machine rid. So the result may be a more specific publish that doesn't work portable.

I think this difference will bite source-build SDK users, and it is preferable to have a flag that means portable-rid consistently.

I do not know the full background why source-build chose to override it, but.. if the value of NETCoreSdkRuntimeIdentifier is overridden in source-build repo for set of reasons, do those same reasons not apply to RuntimeIdentifier?

In other words, --use-current-runtime's docs are stating "Use current runtime as the target runtime.", the one SDK is executing on. This is what we have implemented. It is not strictly calling out portable-rid, that's an internal detail of general (non-overridden, non-source-build) case.

I do not know the full background why source-build chose to override it, but.. if the value of NETCoreSdkRuntimeIdentifier is overridden in source-build repo for set of reasons, do those same reasons not apply to RuntimeIdentifier?

source-build does it to indicate the resulting artifacts are not portable.

In other words, --use-current-runtime's docs are stating "Use current runtime as the target runtime.", the one SDK is executing on. This is what we have implemented. It is not strictly calling out portable-rid, that's an internal detail of general (non-overridden, non-source-build) case.

The main use-case is to enable easy publish for the portable rid.
If this flag enables that on Microsoft sdk, that is what it will be used for.
So I'd like this to have the same behavior on source-build sdk, and we can update the docs/implementation accordingly.

From my perspective, the source-build scenario was being discussed earlier, and this proposal came up that I think was very nice (except maybe the word "machine" in particular, since it doesn't line up with any other concept I'm aware of):

--use-current-runtime, UseCurrentRuntimeIdentifier for portable RID.
--use-current-machine-runtime, UseCurrentMachineRuntimeIdentifier for non-portable RID.

Docs could then consistently use --use-current-runtime, and source-build users can elect to use the non-portable RID if they so choose.

But then this PR was merged without resolving that discussion, abruptly--it seems to me. 😕 (There were also no approvals.)

except maybe the word "machine"

It was adapted from @eerhardt's question #14093 (comment) (and maybe derived from the fact that 'machine config' is a thing in .NET Framework) 😉

nagilson · 2022-10-21T22:43:52Z

@am11 Did we never document this feature publically? Like https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-build, and the publish page, or somewhere like that?

nagilson · 2022-10-22T00:00:58Z

FYI dotnet/docs#31970 adding it here. @am11. We also changed it to become an opt out for implicit rids.

am11 · 2022-10-22T02:07:46Z

FYI dotnet/docs#31970 adding it here

Thanks.

Did we never document this feature publically?

PR added dotnet build --help documentation. It is not obvious that the docs repo requires a manual update each time we modify an option.

nagilson · 2022-10-25T17:29:59Z

We forget to document stuff all the time. Don't sweat it, I agree it would be better if we had something in place for this.

dsplaisted reviewed Oct 12, 2020

View reviewed changes

am11 force-pushed the feature/add_--infer-runtime_options branch from 95a7343 to ebc5ea2 Compare October 12, 2020 22:36

am11 changed the title ~~Add --infer-runtime option~~ Add --use-current-runtime option Oct 12, 2020

Add --use-current-runtime option

52dfbb6

am11 force-pushed the feature/add_--infer-runtime_options branch from ebc5ea2 to 52dfbb6 Compare October 12, 2020 22:54

dsplaisted reviewed Oct 14, 2020

View reviewed changes

src/Cli/dotnet/commands/dotnet-restore/RestoreCommandParser.cs Outdated Show resolved Hide resolved

am11 added 2 commits October 14, 2020 06:26

Use CommonOption in RestoreCommandParser as well

a60f419

Delete unused using

d44027c

dsplaisted reviewed Oct 14, 2020

View reviewed changes

Address PR feedback

f346c3d

marcpopMSFT merged commit 347f78f into dotnet:master Oct 21, 2020

am11 deleted the feature/add_--infer-runtime_options branch October 21, 2020 21:37

tmds reviewed Oct 22, 2020

View reviewed changes

This was referenced Oct 22, 2020

New properties added in 6.0 timeframe #14293

Closed

New/Changed feature to document in 6.0 timeframe #14294

Closed

tmds mentioned this pull request Oct 23, 2020

--use-current-runtime semantics #14296

Closed

marcpopMSFT added the Document for new feature label Feb 17, 2021

dsplaisted mentioned this pull request Jun 28, 2021

Add property for opting out of apphost signing in macOS #18216

Merged

ilharp mentioned this pull request Aug 31, 2021

dotnet publish Targets Different Frameworks when Publishing Multiple Projects #16450

Closed

am11 mentioned this pull request Oct 4, 2022

BundledVersions: update portable rid logic. dotnet/installer#14647

Merged

baronfel removed the Document for new feature label Sep 4, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add --use-current-runtime option #14093

Add --use-current-runtime option #14093

am11 commented Oct 10, 2020 •

edited

Loading

dagood commented Oct 12, 2020

dsplaisted left a comment

am11 commented Oct 12, 2020

dsplaisted left a comment

dsplaisted Oct 14, 2020

am11 Oct 14, 2020

eerhardt commented Oct 14, 2020

janvorli commented Oct 14, 2020

dagood commented Oct 14, 2020

dagood commented Oct 14, 2020

am11 commented Oct 14, 2020 •

edited

Loading

tmds commented Oct 14, 2020

am11 commented Oct 14, 2020

tmds commented Oct 14, 2020

am11 commented Oct 14, 2020

dsplaisted commented Oct 14, 2020

am11 commented Oct 14, 2020 •

edited

Loading

dsplaisted commented Oct 14, 2020

eerhardt commented Oct 14, 2020

tmds Oct 22, 2020

am11 Oct 22, 2020

tmds Oct 22, 2020

dagood Oct 22, 2020 •

edited

Loading

am11 Oct 22, 2020 •

edited

Loading

nagilson commented Oct 21, 2022 •

edited

Loading

nagilson commented Oct 22, 2022

am11 commented Oct 22, 2022

nagilson commented Oct 25, 2022

	<value>Use host runtime to build the target.</value>
	<value>Use current runtime as the target runtime.</value>

Add --use-current-runtime option #14093

Add --use-current-runtime option #14093

Conversation

am11 commented Oct 10, 2020 • edited Loading

dagood commented Oct 12, 2020

dsplaisted left a comment

Choose a reason for hiding this comment

am11 commented Oct 12, 2020

dsplaisted left a comment

Choose a reason for hiding this comment

dsplaisted Oct 14, 2020

Choose a reason for hiding this comment

am11 Oct 14, 2020

Choose a reason for hiding this comment

eerhardt commented Oct 14, 2020

janvorli commented Oct 14, 2020

dagood commented Oct 14, 2020

dagood commented Oct 14, 2020

am11 commented Oct 14, 2020 • edited Loading

tmds commented Oct 14, 2020

am11 commented Oct 14, 2020

tmds commented Oct 14, 2020

am11 commented Oct 14, 2020

dsplaisted commented Oct 14, 2020

am11 commented Oct 14, 2020 • edited Loading

dsplaisted commented Oct 14, 2020

eerhardt commented Oct 14, 2020

tmds Oct 22, 2020

Choose a reason for hiding this comment

am11 Oct 22, 2020

Choose a reason for hiding this comment

tmds Oct 22, 2020

Choose a reason for hiding this comment

dagood Oct 22, 2020 • edited Loading

Choose a reason for hiding this comment

am11 Oct 22, 2020 • edited Loading

Choose a reason for hiding this comment

nagilson commented Oct 21, 2022 • edited Loading

nagilson commented Oct 22, 2022

am11 commented Oct 22, 2022

nagilson commented Oct 25, 2022

am11 commented Oct 10, 2020 •

edited

Loading

am11 commented Oct 14, 2020 •

edited

Loading

am11 commented Oct 14, 2020 •

edited

Loading

dagood Oct 22, 2020 •

edited

Loading

am11 Oct 22, 2020 •

edited

Loading

nagilson commented Oct 21, 2022 •

edited

Loading