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

[KathleenDollard]

dotnet run has an abbreviation inconsistent with its sister commands dotnet build and dotnet publish. This proposal is to change that with a deprecation path for the current usage.

[dsplaisted]

Looks good. I think we should also describe how this will be a breaking change:

• In cases where the output of dotnet run is being parsed
• In cases where the path to a project file passed in via -p includes an =

[dsplaisted]

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>`.

[dsplaisted]

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).

[dsplaisted]

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.

[dsplaisted]

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.

[dsplaisted]

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.

[dsplaisted]

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:

[dsplaisted]

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.

[dsplaisted]

Per prior comment, probably this line can be dropped.

[dsplaisted]

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`.

[dsplaisted]

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.

[dsplaisted]

Suggested change

	If you have any scripts that are using “dotnet run” and process the output you could encounter a break. dotnet run typically doesn’t output anything of its own if there are no errors, so you only get the output of the program that is being run. If you have a script or other program wrapping “dotnet run” and parsing the output, the warning would be unexpected text and may cause a failure.
	If you have any scripts that are using `dotnet run` and process the output you could encounter a break. `dotnet run` typically doesn’t output anything of its own if there are no errors, so you only get the output of the program that is being run. If you have a script or other program wrapping `dotnet run` and parsing the output, the warning would be unexpected text and may cause a failure.

[dsplaisted]

@KathleenDollard Are you going to look at the feedback and eventually merge this?