You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
baronfel opened this issue
Jun 22, 2022
· 1 comment
Assignees
Labels
Area-CLIcli-uxIssues and PRs that deal with the UX of the CLI (exit codes, log output, verbs/options, and so on)untriagedRequest triage from a team member
Is your feature request related to a problem? Please describe.
Currently, users can define PublishProfiles for use with dotnet publish. These profiles are XML Project files that contain properties unique to a specific
a) publish mechanism, like a filesystem folder containing all of your assets, or a build of a Dockerfile), and
b) publish target, like the filesystem folder to which to publish, or the external Registry to push the generated Docker image to
The default publish profile is a filesystem publish to the /publish directory, and users are likely already quite familiar with the behavior of this, but there are several others included in the SDK, and various tooling in Visual Studio (and other mechanisms) will scaffold out PublishProfiles on your behalf.
To use a specific publish profile, the user has to add the following MSBuild property: /p:PublishProfile=<Name of profile>. This is obtuse and easy to typo.
Describe the solution you'd like
I propose a new string Option be added to the publish Command - [--profile PUBLISH_PROFILE_NAME]. This command must take a single argument that is the file name (without extension) of a PublishProfile that exists in <project root>/Properties/PublishProfiles OR the name of one of the in-box, default PublishProfiles (which are located here) . The user-provided value will be forwarded to the Publish target as the value of the MSBuild property PublishProfile. Tab-completion for this property can be quickly determined based on these files, but we should probably filter the list by the value of the WebPublishMethod inside the PublishProfile itself - some methods do not work on non-Windows systems.
Example usage
# shows an example invocation
> dotnet publish --profile PushToAzure
# shows how tab completion with no text stem looks
>dotnet publish --profile <TAB>
Default
DefaultMSDeploy
DefaultMSDeployPackage
DefaultZipDeploy
PushToAzure
The text was updated successfully, but these errors were encountered:
Area-CLIcli-uxIssues and PRs that deal with the UX of the CLI (exit codes, log output, verbs/options, and so on)untriagedRequest triage from a team member
Is your feature request related to a problem? Please describe.
Currently, users can define PublishProfiles for use with
dotnet publish
. These profiles are XML Project files that contain properties unique to a specifica) publish mechanism, like a filesystem folder containing all of your assets, or a build of a Dockerfile), and
b) publish target, like the filesystem folder to which to publish, or the external Registry to push the generated Docker image to
The default publish profile is a filesystem publish to the
/publish
directory, and users are likely already quite familiar with the behavior of this, but there are several others included in the SDK, and various tooling in Visual Studio (and other mechanisms) will scaffold out PublishProfiles on your behalf.To use a specific publish profile, the user has to add the following MSBuild property:
/p:PublishProfile=<Name of profile>
. This is obtuse and easy to typo.Describe the solution you'd like
I propose a new string Option be added to the publish Command -
[--profile PUBLISH_PROFILE_NAME]
. This command must take a single argument that is the file name (without extension) of a PublishProfile that exists in<project root>/Properties/PublishProfiles
OR the name of one of the in-box, default PublishProfiles (which are located here) . The user-provided value will be forwarded to the Publish target as the value of the MSBuild propertyPublishProfile
. Tab-completion for this property can be quickly determined based on these files, but we should probably filter the list by the value of theWebPublishMethod
inside the PublishProfile itself - some methods do not work on non-Windows systems.Example usage
The text was updated successfully, but these errors were encountered: