dotnet restore fails, but reports success

[ghost]

Copied from issue NuGet/Home#10606 per jeffkl's guidance

Details about Problem

Cross posting from dotnet sdk, as it isn't clear if this issue is in the sdk or the nuget client used in that sdk.
Repro posted on dotnet/sdk#16031 (comment)

Product version:

dotnetsdk 3.1.406

Repro steps and/or sample project

Repro is simple. Try to restore a package that doesnt exist. E.g. Microsoft.Build.Traversal2

aaronla@aaronla-rabbit:MyRepo$ dotnet restore
X:\MyRepo\dirs.proj : error : Unable to find package Microsoft.Build.Traversal with version (= 2.999.1)
X:\MyRepo\dirs.proj : error :   - Found 24 version(s) in MyCustomFeedOne [ Nearest version: 3.0.0 ]
X:\MyRepo\dirs.proj : error :   - Found 0 version(s) in MyCustomFeedTwo

aaronla@aaronla-rabbit:MyRepo$ echo %ERRORLEVEL%
0

Verbose Logs

[jeffkl]

This is currently happening because restore is trying to do a "best effort" of loading the project and executing restore. Sometimes restore itself will pull in build logic from a package but the project can't be evaluated until restore is done. So we set some special flags during restore to accomplish this:

https://github.com/dotnet/msbuild/blob/main/src/MSBuild/XMake.cs#L1424-L1426

The logic to fail gracefully if an SDK isn't found was added in #2991 so that users in Visual Studio would get a better experience.

From the command-line, this logic culminates in a project loaded with no errors and potentially no targets, then nothing is executed and since there are no real errors the build succeeds. The intention of ignoring invalid imports is more about trying to successfully load a project even if stuff is missing. However, later on when we build, it should still fail if the project is "invalid".

We'll probably need to add a new flag that we specify at the command-line that says an SDK resolution failure is considered fatal. This will allow Visual Studio to still load the project as intended. Other missing imports can still be ignored and hopefully they'll show up during build since they could be restored from a package.

[ghost]

Makes sense. Just make sure that flag is set to true when either invoking the msbuild /t:Restore or restore dotnetcli commands, as it should be fatal for those commands.

If I ask dotnet to restore, and it doesn't, that should clearly be considered a failure.

[benvillalobos]

Team Triage: @jeffkl is this something you wanted to tackle? it sounds like we'll need to catch restore as a command line arg and pass it along to account for this.

[jeffkl]

Yes sorry I couldn’t make it to today’s sync, I’ll attend next week to talk through the options.

[jeffkl]

@benvillalobos please assign this issue to me

[ghost]

@jeffkl will this be available on either the 3.1 or 5.0 sdks? We're currently on 2.1, but in process of moving to the current LTS (3.1).

[ghost]

Confirmed fixed in 6.0.100-preview.6.21271.8