Add default for dotnet reference list Fixes #48555

[Forgind]

Fixes #48555

This was a very good bug report, very easy to reproduce. My first look suggested that it was just the HasOption issue, but that was only half of the problem; there was an issue with what the default of the argument should be that I hadn't expected. In particular, there was a default "built into" System.CommandLine's Argument, and since that argument wasn't added to reference list (intentionally, as it wasn't supposed to be supported long-term), accessing it returned null. I fixed that by coalescing that to the current directory, that has the intended behavior.

Before:

>dotnet list reference
There are no Project to Project references in project C:\bugs\temp\.

>dotnet reference list
Could not find project or directory ``.

After:

>dotnet reference list
There are no Project to Project references in project C:\bugs\temp.

>dotnet reference list --project temp.csproj
There are no Project to Project references in project temp.csproj.

The one shift I noticed is that it lost a DirectorySeparatorChar. It shouldn't matter, I think, since it loads the directory as DirectoryInfo and grabs all *proj under that, but I can change that if you're aware of a way that that breaks things.

[Copilot]

Pull Request Overview

This PR fixes a bug in the dotnet reference list command by ensuring that when no project argument is provided, the command defaults to using the current directory.

• Introduces a null-coalescing operation to default the value from ListCommandParser.SlnOrProjectArgument to Directory.GetCurrentDirectory()
• Addresses an edge-case where accessing a built-in default resulted in a null value

[Copilot]

[nitpick] Consider explicitly handling directory formatting (e.g., trailing DirectorySeparatorChar) when defaulting to Directory.GetCurrentDirectory() to maintain consistency with file path expectations.

Suggested change

	Directory.GetCurrentDirectory();
	(Directory.GetCurrentDirectory().EndsWith(Path.DirectorySeparatorChar)
	? Directory.GetCurrentDirectory()
	: Directory.GetCurrentDirectory() + Path.DirectorySeparatorChar);

[v-wuzhai]

One small observation: when running dotnet reference list with an explicitly provided project via --project and when relying on the implicit default (current directory), the output message differs slightly:

> dotnet reference list
There are no Project to Project references in project C:\bugs\temp.
> dotnet reference list --project temp.csproj
There are no Project to Project references in project temp.csproj.

Although both commands resolve to the same project, the output format is inconsistent — one reflects the directory path, the other the project file name. This difference in output for what is functionally the same command might be confusing to users.

It might be worth considering normalizing the output to always display the resolved project file path (e.g., full path to the .csproj), regardless of whether the project was specified explicitly or implicitly.

[Forgind]

One small observation: when running dotnet reference list with an explicitly provided project via --project and when relying on the implicit default (current directory), the output message differs slightly:

> dotnet reference list
There are no Project to Project references in project C:\bugs\temp.
> dotnet reference list --project temp.csproj
There are no Project to Project references in project temp.csproj.

Although both commands resolve to the same project, the output format is inconsistent — one reflects the directory path, the other the project file name. This difference in output for what is functionally the same command might be confusing to users.

It might be worth considering normalizing the output to always display the resolved project file path (e.g., full path to the .csproj), regardless of whether the project was specified explicitly or implicitly.

I think this is a fair argument. My counterargument would be that if a user inputs a particular path or file, we should parrot back exactly what they inputted without modification. I don't really have a strong opinion either way, though.

[edvilme]

Seems good to me!