Steps to reproduce

1. Open existing dotnet project in Emacs
2. M-x dotnet-with-args

Expected

Receive an interactive prompt to input arguments, then run dotnet app.

Actual

Receive error message in minibuffer: Invalid control letter ‘A’ (#o101, #x0041) in interactive calling string

Recommended solution

One line fix inside dotnet-run-with-args:

(interactive "sArguments: ")

According to Emacs Wiki:

Example of a command that reads a string argument:

    (defun hello (someone)
      "Say hello to SOMEONE via M-x hello."
      (interactive "sWho do you want to say hello to? ")
      (message "Hello %s!" someone))

I can submit a PR --I've been using this in my local env already --but wanted to make sure this is the intended behavior first.

I'm wondering if it may be useful to add a shortcut to call dotnet watch run or dotnet watch test to have the build refresh on code changes. I anticipate it would behave just like the current prefix e but would refresh when a file is saved and changed.

Right now if dotnet-build fails, it doesn't highlight errors.

If I manually invoke M-x compile and use "dotnet build" as the command I get the links to the code.

I think it would be better if C-n t asked which tests to run the first time and from there on acted like C-n T.
And if you want to run a different test command, then you can get queried again with C-n T.
It feels more natural/emacsy.

Another option which is even more Emacs-like would be to have C-n t query the first time, then re-run, and use a prefix arg to get queried again. C-u C-n t would make you provide the project again.

If you agree with the suggestion, I can provide a pull request with either change.
There's nothing wrong with the way it works now, that's why I'm checking for your thoughts before coding anything.

In the last few days I've using dotnet in a multi-project repo.

I've found myself using the prefix args submitted in my last pull request. Also in my local dotnet.el I added more variables to keep track of the last project for build, run, etc. At this rate each function will have it's own variable!!!

I think it would be convenient to have a way to setup a default project so that all commands use it, and allow overrides with C-u.

Sample workflow:

1. Open some .cs files. Start working
2. Call dotnet-build, get prompted for csproj/solution
3. [Maybe?] Get prompted to make this the default for subsequent calls with y/n question
4. Keep using the same default (if set) unless the command is called with C-u prefix

I think most commands could share the same default, except dotnet-run: build, add reference, etc can work on a whole solution but you usually run only one project within the solution directories.

So in essence we would need 2 variables to track the "current project".
I also think it would be great to show the current projects in the echo area when the dotnet-mode keymap is active, if possible, so you know that you need to add an arg to your call.

This adds some complexity to the package, though, and changes it's behaviour quite a bit. So unless you see an use for these changes yourself, I can keep these in my own branch (when I get around to making them hehe)