dotnet package list command should restore first

[Nigusu-Allehu]

Fixes: NuGet/Home#13406

Description

This PR

• Adds implicit restore to dotnet package list command or dotnet list package (Switch verb and noun for package/reference add/remove/list Fixes #9650 #45384)

[Nigusu-Allehu]

These tests are copied from dotnet-list-package.Tests\GivenDotnetListPackage.cs. They are the same commands. #45384

[nkolev92]

I'm wondering if the Please try running dotnet restore`` is the right action to suggest to the user.
I'd expect that restore fails as well.

[Nigusu-Allehu]

Good point! I see how the message could be misleading, as it might imply that running dotnet restore would necessarily fix the issue. A more accurate message could be:
"Restore failed. Run dotnet restore for more details on the issue."

[nkolev92]

After this change, how does the restore error appear?

Basically, can you show us a full output of a dotnet list package call that has a failed restore (say becausie a package does not exist).

[Nigusu-Allehu]

It would look as follows

Restore failed. Please try running dotnet restore.

Restore is executed with the "-noConsoleLogger" option to suppress all logging from the restore process. This ensures that restore messages do not interfere with the package listing logs. If restore fails, we detect it via the exit code and log an error message.

The primary reason for suppressing restore logs is to prevent them from disrupting structured outputs, such as when the user specifies --format json, where additional messages could result in invalid JSON. Given this, the approach is to avoid logging any restore output and, in case of failure, simply inform the user and recommend running dotnet restore to investigate the issue.

[nkolev92]

If a user specifies --format json and we put this custom error, doesn't that still break the structured log?
It's going to be pretty challenging to chain the commands and get the output.

[nkolev92]

Hmm, that complicates the integration effectively, cause we'd need to write that from this code right, not the NuGet side code.

Is there a way we can "capture" the logs?

[Nigusu-Allehu]

We could have it on the nuget side by forwarding through an option like
--restore-failed and do the logging from xplat

[nkolev92]

@dotnet/nuget-team thoughts?

[zivkan]

My opinion is that dotnet add package already knows how to restore, dotnet package update is going to need to as well, and dotnet nuget why also needs it, in addition to dotnet list package. I think we should make the effort to do everything in the NuGet.Client repo, which also makes it easier for us to test. Splitting our business logic across multiple repos increases tech debt.

[Nigusu-Allehu]

For all these commands, we could move their invocation methods into the NuGet.Client repo, allowing the SDK to call these methods directly instead of forwarding command arguments to xplat.

By doing so, we can introduce a wrapper on the SDK side—let’s call it RestoringCommandsWrapper. This class would ensure that restore operations execute before any dependent command runs.

Example:
Instead of directly executing commands like dotnet nuget why, we could wrap them in a RestoringCommandsWrapper:

public class RestoringCommandsWrapper
{
    public static void Execute()
    {
        // Execute restore first
        RestoreCommand.Execute();

        // Execute the actual command
        command(argss);
    }
}

Then, for commands like dotnet nuget why, we would update the invocation to:

RestoringCommandsWrapper.Execute(() => 
    NuGet.CommandLine.XPlat.Commands.Why.WhyCommand.RunWhyCommand(whyArgs), whyArgs);

Currently, for dotnet nuget why, we invoke a method on the client side that adds nuget why to the root command:

NuGet.CommandLine.XPlat.Commands.Why.WhyCommand.GetWhyCommand(command);

Instead of this approach, we could perform all parsing on the SDK side and use:

NuGet.CommandLine.XPlat.Commands.Why.WhyCommand.RunWhyCommand(whyArgs);

If why is a restoring command, we could use the RestoringCommandsWrapper to ensure restore runs before executing the command.