Command line argument for solution/project as positional argument

[MaStr11]

Fixes #489

dotnet-format:
  dotnet-format

Usage:
  dotnet-format [options] [<project>]

Arguments:
  <project>    Die Projektmappe oder Projektdatei, die verwendet werden soll. Wenn keine Datei angegeben ist,
               durchsucht der Befehl das aktuelle Verzeichnis nach einer Datei.

Options:
  -f, --folder <folder>           The folder to operate on. Cannot be used with the `--workspace` option.
  -w, --workspace <workspace>     Die Projektmappe oder Projektdatei, die verwendet werden soll. Wenn keine Datei
                                  angegeben ist, durchsucht der Befehl das aktuelle Verzeichnis nach einer Datei.
  --files, --include <include>    A list of relative file or folder paths to include in formatting. All files are
                                  formatted if empty.
  --exclude <exclude>             A list of relative file or folder paths to exclude from formatting.
  --check, --dry-run              Formats files without saving changes to disk. Terminates with a non-zero exit code
                                  if any files were formatted.
  --report <report>               Accepts a file path, which if provided, will produce a json report in the given
                                  directory.
  -v, --verbosity <verbosity>     Legen Sie den Ausführlichkeitsgrad fest. Zulässige Werte sind "q[uiet]",
                                  "m[inimal]", "n[ormal]", "d[etailed]" und "diag[nostic]".
  --version                       Show version information
  -?, -h, --help                  Show help and usage information

[MaStr11]

Allows to specify the workspace as first argument:

dotnet-format Solution.sln --verbosity d
dotnet-format --verbosity d Solution.sln
dotnet-format Solution.sln -w Project.scproj

At the moment the -w option takes precedence over the positional argument.

[JoeRobich]

@MaStr11 Thanks for implementing this! This transition would be a awkward for a little while, but I feel it is an improvement overall.

I think we should consider what the options would be if we were starting from scratch. Maybe it would look something like the following:

dotnet-format:
  dotnet-format

Usage:
  dotnet-format [options] [<workspace>]

Arguments:
  <workspace>                     The path to the solution or project file to operate on. If a file is not specified, the command will search the current directory for one.

Options:
  -f, --folder                    Treat the <workspace> as a folder path and discover code files beneath it without loading a solution or project.
  -v, --verbosity <VERBOSITY>     Set the verbosity level. Allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]
  --check                         Runs formatters but does not save changes. If any files would have been changed, terminates with a non-zero exit code.
  --include <INCLUDE>             A comma separated list of relative file or folder paths to include in formatting. All files are formatted if empty.
  --exclude <EXCLUDE>             A comma separated list of relative file or folder paths to exclude from formatting. No files are excluded if empty.
  --report <REPORT>               Accepts a file path, which if provided, will produce a json report in the given directory.
  --version                       Display version information

So to help us reach this goal, it would be nice to provide the user with some errors and warnings.

• If they supply a --workspace | -w without supplying the <workspace> argument, we could give a warning to use the argument.
• If they supply a --workspace | -w in addition to the <workspace> argument, we should error and inform them to only supply the argument.
• If they supply a --folder | -f in addition to the <workspace> argument, we should error and inform them to use one or the other.

Later we can make the breaking change that --folder | -f should become a bool flag. That --dry-run produces a warning to use --check. That --files produces a warning to use --include.

What are your thoughts about adding the <workspace> related warnings in this PR? If you are busy and would rather not, I would be happy to follow up and add them.

[MaStr11]

What are your thoughts about adding the related warnings in this PR? If you are busy and would rather not, I would be happy to follow up and add them.

@JoeRobich I can definitely do that. I intentionally only did the most basic implementation to get the discussion started. I like the deprecation idea. I will start implementing now and will get back to you later.

[jmarolf]

I am also in favor of making a breaking change here and just bumping the version number

[MaStr11]

This check is now done in the validator (ValidateWorkspaceAndFolder). Should I remove it here?

[JoeRobich]

Please do. =)

[MaStr11]

Ready for review.

[JoeRobich]

Thanks!