[VS IDE] _PublishSingleContainer[CreateNewImage] operation will result in SUCCESS whether target container repository is reachable or un-authorized

[anvillan]

When publishing a container image through the .NET SDK Containers support "Target:_PublishSingleContainer, Task:CreateNewImage", the result returned to the caller is always SUCCESS (True, no excepction(s) thrown) even:

• The target container registry is not reachable
• The credentials passed to the invocation are valid or not (e.g. empty values)
• Reproduced on .NET 9 and .NET 10 (RC)

Repro steps:

• In VS, using a ASP.NET Web App project

1. Create Publish profile
   1.1. Right click on the Project -> Publish
   1.2. In the Publish Wizard Dialog, select "Docker Container Registry" (Next) => "Azure Container Registry" (Next)
   1.3. Select or create an Azure Container Registry (Next)
   1.4. Select ".NET SDK" as the Container Build (Finish)

2. Edit profile to point a non-existing ACR
   Under the ../<ProjectDir>/Properties/PublishProfiles open the publish profile (.pubxml) just created and edit it to point an incorrect container registry. Edit the properties:

• "ResourceId"
• "ResourceName"
• "RegistrUrl"
  and set to a non-existing instance. I.e. add "x" at the name of the container

3. Publish the project with the just edited profile (Click Publish button)

EXPECTED:
Tthe .NET SDK Container target (task) is invoked, and it fails as the ACR is not reachable and the credentials are not valid (they are empty as target container does not exist). No image is pushed into the Azure Container Registry.

ACTUAL:
The .NET SDK Container target (task) is invoked, and it result in SUCCESS, with no error/exceptions thrown because of the non-reachable container registry. No image is pushed into the Azure Container Registry.

[baronfel]

This would likely repro on .NET 8 as well, we haven't really changed this interaction in quite a long time.

I suspect that errors aren't being returned as non-zero exit codes in the MSBuild ToolTask - we'd need to check if invocations of the exe a) do return nonzero exit codes, and b) those codes are interpreted correctly by the MSBuild ToolTask infrastructure.

For .NET 10+, we could consider not fixing this at all and just using the .NET TaskHost mechanism, but we should fix this in servicing for .NET 8 and .NET 9.