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

Should the CLI support user default setting values #9344

Open
spboyer opened this issue May 3, 2018 · 9 comments
Open

Should the CLI support user default setting values #9344

spboyer opened this issue May 3, 2018 · 9 comments
Assignees
Labels
Area-CLI config-system-candidate Issues that could be solved cleanly if the .NET CLI had a git-like configuration system
Milestone

Comments

@spboyer
Copy link
Contributor

spboyer commented May 3, 2018

Working with a Razor Pages app. Having to type the namespace value over and over when adding a new page to the application.

> dotnet new page --name Index -na MyAppName.Pages.Area -o Pages/Area

> dotnet new page --name NextPage -na MyAppName.Pages.Area -o Pages/Area

Solved with creating local variable

> ns=-ns=MyAppName.Pages

> dotnet new page --name Index  $ns.Area -o Pages/Area

The Azure CLI offers user defaults once set the user does not have to specify them in the actual command at all.

az configure --defaults location="East US" group="mysuperappgroup" 

[defaults]
location = East US  
group = mysuperappgroup 

# create a web application usually needing the above location and group specified.
az appservice web create -n myapp

It would suffice that the dotnet application should support this feature for things like --framework, --language, --nuget-source etc. without having to have the developer script specifically via bash, powershell or some other means.

@livarcocc
Copy link
Contributor

@KathleenDollard @nguerrera another application for dotnet config

@ghost
Copy link

ghost commented May 4, 2018

In .gitconfig we can define aliases like:

[alias]
    dnc = !dotnet new console -n $2
etc.

docs: https://git-scm.com/docs/git-config

with usage: git dnc myConsoleApp. This works across the platforms/shells (as git installer itself packs unix shell in Windows for cmd/powershell usage). .dotnetconfig or .netconfig with [alias] support would be a great match!

@KathleenDollard
Copy link

This sounds cool.

Downsides?

@spboyer
Copy link
Contributor Author

spboyer commented May 4, 2018

You can do aliases many ways. .gitconfig is a clever way to do it xplat. However having functionality core to the CLI would be more expected.

Aliases are a way for devs to personalize their experience for their machines and tools, add shortcuts etc on top of the experience the tools give us out of the box.

@KathleenDollard
Copy link

I was too brief.

I meant, any downsides to adding the ability to do aliases in the dotnet CLI itself. I don't want to require any other tools for basic behavior.

@nguerrera
Copy link
Contributor

I'm biased because I've said that I've wanted this a lot, but I don't think there are downsides. 😄

@msftgits msftgits transferred this issue from dotnet/cli Jan 31, 2020
@msftgits msftgits added this to the Backlog milestone Jan 31, 2020
@egvijayanand
Copy link

egvijayanand commented Mar 25, 2023

Git supports configuring command aliases so that frequently used commands can be used with fewer keystrokes.

For example: git pull origin main

Have configured it as pom so that it can be used as git pom with the help of the below command.

git config --global alias.pom "pull origin main"

Similar to this, kindly consider enabling the option in dotnet CLI commands to configure aliases so that frequent commands can be used in fewer keystrokes.

dotnet new maui-page-csharp -n HomePage -p:n MyApp.Views

This can be configured as dotnet mpc (user configurable aliases).

Configuring placeholders can also be considered so that using the hyphen(s) as prefixes can be avoided in the usage. In the same dotnet new command, the name can be the first placeholder and the namespace as the second placeholder.

dotnet new maui-page-csharp -n $1 -p:n $2

@baronfel baronfel self-assigned this Oct 13, 2023
@baronfel baronfel added the config-system-candidate Issues that could be solved cleanly if the .NET CLI had a git-like configuration system label May 2, 2024
@Evangelink
Copy link
Member

Evangelink commented Dec 13, 2024

I would love to use the aliasing system for dotnet test. There are currently many ways for users to run their tests but dotnet test is tied to VSTest. We are currently working on allowing Microsoft.Testing.Platform instead but I think it would be awesome if any test tool could be plugged and called when doing dotnet test. This would for example allow xUnit (cc @bradwilson) to have its own runner as the runner behind dotnet test call. Obviously the available arguments would differ but as explained above this is just setting some user preference.

cc @MarcoRossignoli @mariam-abdulla

@bradwilson
Copy link
Contributor

This is essentially what dotnet run does now for us, except that of course dotnet test as it is today will do the restore & build, and can run multiple test projects, where as dotnet run for us is limited to running a single project.

We used to have dotnet xunit a long time ago as a .NET Core version of our console multi-runner. Like our console runner, it did not have any of the restore or build behavior: it expected to be passed paths to already build test project binaries.

I'm not sure how to reconcile all of this w/rt to plugging in, in a way that doesn't already look like VSTest or Microsoft Testing Platform. I guess I'd want to see examples of what your anticipated usage looks like and how you'd envision that being handed off to us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-CLI config-system-candidate Issues that could be solved cleanly if the .NET CLI had a git-like configuration system
Projects
None yet
Development

No branches or pull requests

9 participants