Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spec for resolving '-p' in 'dotnet run' #229

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions accepted/2021/dotnet-run-resolve-p.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
# Syntax for passing properties to MSBuild in `dotnet run`

Kathleen Dollard | Status: Draft

The .NET CLI passes all command line arguments that are not explicitly handled through to MSBuild for `dotnet build` and `dotnet publish`. This does not work for `dotnet run` because there are three sets of arguments:

* CLI arguments for `dotnet run` itself.
* Arguments for the resulting application, identified by `--`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use -- to identify arguments for the resulting application, but you don't have to. Unrecognized arguments will be passed through. So part of the difference between dotnet run and other commands is that dotnet run passes unrecognized arguments to the app it runs, while other commands pass them through to MSBuild.

This also means that any parameters we add to dotnet run are breaking changes, as if an app was previously using those parameters and they were being passed through to it without --, then the app will no longer get them.

* MSBuild arguments, which are not currently supported.

To support the Xamarin/Maui workloads, we need to pass a property to MSBuild that specifies the device to target. This is being solved by adding a `--property` option to `dotnet run`. This will route to MSBuild as `-p:<delimited list>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
To support the Xamarin/Maui workloads, we need to pass a property to MSBuild that specifies the device to target. This is being solved by adding a `--property` option to `dotnet run`. This will route to MSBuild as `-p:<delimited list>.
To support the Xamarin/Maui workloads, we need to pass a property to MSBuild that specifies the device to target. This is being solved by adding a `--property` option to `dotnet run`. This will route to MSBuild as `-p:<delimited list>`.


**Note:** A long term approach to managing “device” selection is planned for a later release. In .NET 6 CLI usage of these workloads is expected to just be CI, so this is not considered critical, and the design work is expected to include adjacent problems of specifying containers, and x64 emulation).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: get rid of smart quotes

Suggested change
**Note:** A long term approach to managing device selection is planned for a later release. In .NET 6 CLI usage of these workloads is expected to just be CI, so this is not considered critical, and the design work is expected to include adjacent problems of specifying containers, and x64 emulation).
**Note:** A long term approach to managing "device" selection is planned for a later release. In .NET 6 CLI usage of these workloads is expected to just be CI, so this is not considered critical, and the design work is expected to include adjacent problems of specifying containers, and x64 emulation).


A problem arises in the abbreviation. `-p`. It is currently used to specify the `--project` for `dotnet run`. This proposal is a course to change `-p` from meaning `--project` to `--property` in order to be consistent with the similar commands - `dotnet build` and ` dotnet publish`. This proposal balances backward compatibility and consistency with other commands, which we can do because the usages can be distinguished syntactically.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
A problem arises in the abbreviation. `-p`. It is currently used to specify the `--project` for `dotnet run`. This proposal is a course to change `-p` from meaning `--project` to `--property` in order to be consistent with the similar commands - `dotnet build` and ` dotnet publish`. This proposal balances backward compatibility and consistency with other commands, which we can do because the usages can be distinguished syntactically.
A problem arises in the abbreviation `-p`. It is currently used to specify the `--project` for `dotnet run`. This proposal is a course to change `-p` from meaning `--project` to `--property` in order to be consistent with the similar commands - `dotnet build` and ` dotnet publish`. This proposal balances backward compatibility and consistency with other commands, which we can do because the usages can be distinguished syntactically.


During a deprecation phase, which will be at least the length of .NET 6, older usage of `-p` as `--project` will be recognized as when there is no trailing colon (`-p:`) and the argument is not legal for MSBuild. Users will receive a warning that the abbreviation is deprecated.

We will identify usage as `--property` when the argument is legal MSBuild syntax. Legal MSBuild syntax will be defined as:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
We will identify usage as `--property` when the argument is legal MSBuild syntax. Legal MSBuild syntax will be defined as:
We will interpret `-p` as `--property` when the argument value is legal MSBuild syntax. Legal MSBuild syntax will be defined as:


* A comma or semi-colon delimited strings of values in the format <name>=<value> or <name>:<value>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we don't need to worry that it's a comma or semi-colon delimited list for detecting whether it's legal for MSBuild, because many usages will only have one property name and hence won't have a delimiter. So we should just say we look to see whether there is an = in the parameter value (or possibly : if that's legal to separate the property name from the value).


## Goals

We believe that in the long term `-p` should be used consistently across `dotnet build`, `dotnet publish` and `dotnet run` because of similarity between these commands.

### Design

The basic design is described in the opening:

* `-p` with syntax that is valid for MSBuild properties will be treated as `--property`.
* `-p:` will be passed to MSBuild so the an MSBuild error is displayed when the argument is illegal.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should drop the distinction between -p <value> and -p:<value> from this proposal. The -p:<value> form currently works as --project, so I don't think we should treat it any differently.

* Any other usage will be treated as `--project` and will receive a warning that this use is deprecated.
* Usage in the form `-p:` will be allowed but not encouraged or documented.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per prior comment, probably this line can be dropped.

* At some future point, we will remove `-p` for `--project`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure we need to commit to eventually removing -p as --project.

Suggested change
* At some future point, we will remove `-p` for `--project`.
* At some future point, we may remove `-p` for `--project`.


### Warning text

When -p is used (with no colon) in .NET 6, the following warning will be displayed:

*“The abbreviation of -p for --project is deprecated. Please use --project.”*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
*The abbreviation of -p for --project is deprecated. Please use --project.*
> Warning NETSDKNNNN: The abbreviation of -p for --project is deprecated. Please use --project.
Where `NNNN` will be replaced with an SDK error code. In contrast to many other errors and warnings generated by the .NET SDK, this warning will be generated by the .NET CLI parsing code instead of flowing through MSBuild. So it will not be affected by "warn as error" or "ignore warning" MSBuild settings.

I'm not sure about the exact formatting we should use for the warning and error code.


### Implementation notes

We are displaying a deprecation warning for `-p` in .NET 6 and hope to do the additional work to support `-p`. However, once the deprecation is in place, we can add the abbreviation in a feature band (quarterly) release.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
We are displaying a deprecation warning for `-p` in .NET 6 and hope to do the additional work to support `-p`. However, once the deprecation is in place, we can add the abbreviation in a feature band (quarterly) release.
We plan to display a deprecation warning for `-p` in .NET 6 and hope to do the additional work to support `-p` as `--property`. However, once the deprecation is in place, we can add the abbreviation in a feature band (quarterly) release.



## Q & A