How to set CanShowDialog from MSBuild? about artifacts-credprovider HOT 15 CLOSED

Makes sense.

If the auth failed because of a timeout (user never entered anything), it would be nice to have a clear error message at the end ("User was presented with device flow, but didn't react after X seconds"). So we know why auth failed.

from artifacts-credprovider.

@satbai

The plugin itself does not have control over the color schema of the logging since the nuget tools write the output.

You can however change the content of the log message to make it pop a bit more.

Potentially you could log at a warning level that would change the color of the output, but that's a misuse.

from artifacts-credprovider.

As a side-note, there's been requests/suggestions that device flow should be the experience every time. (Even NuGet.exe)
//cc @loic-sharma

If the auth failed because of a timeout (user never entered anything), it would be nice to have a clear error message at the end ("User was presented with device flow, but didn't react after X seconds"). So we know why auth failed.

I think the plugin should/can handle that.

from artifacts-credprovider.

@KirillOsenkov There is no way to do that.

By design MSBuild will never allow plugins to pop-up a dialog.
This was a decision made jointly between NuGet and @jeffkl and @AndyGerlicher.

We thought it's important that the host (msbuild,dotnet.exe) makes the decision on what the experience will be like.
//cc @rrelyea

from artifacts-credprovider.

@KirillOsenkov we didn't like the idea of a command-line tool like MSBuild.exe popping up a dialog and opted to use device flow instead which prompts in the same command window. Do you not like this approach?

from artifacts-credprovider.

I'm taken by surprise that this was a deliberate decision ;)

What is happening is you're pausing the build and prompting for user interaction via device flow, and then fail after a certain timeout if user didn't auth. So in a way it is already interactive, just not showing a dialog.

But the unfortunate UX of this is the user launched the build, specified /p:nugetInteractive=true, fully expecting a dialog to pop up, and switched away to reading Twitter, waiting for that dialog. The device flow prompt was buried in a sea of random output, and after I get tired of Twitter I switch back to MSBuild only to find out that the auth failed for some unknown reason.

I certainly understand that MSBuild showing dialogs sounds nonsensical, however I'd rather have that than the device flow experience, honestly. Two improvements come to mind:

1. Highlight the device flow prompt using a bright console color, surround with ASCII frames and make sure it's the last thing in the MSBuild output console, and not buried in random output.

2. Allow the user to pass a property to switch to the auth dialog if they so choose. You can keep device flow as default, if it is more discoverable. But there needs to be an option at least.

from artifacts-credprovider.

I personally expect all prompts to come from the command window itself. I've had command-line tools pop up dialogs and sometimes they appear behind my windows which is bad. They also cannot be made modal so I can bring the command window back to focus and not know that it has popped up this other unrelated window.

I think the biggest reason we didn't want to pop up a dialog is because MSBuild is cross platform and we wouldn't be able to open a consistent looking dialog on the various platforms. This means that MSBuild.exe would pop up a dialog while dotnet msbuild would not, even on the same machine. Even if we made MSBuild pop up a dialog on Windows only, I think it would be bad if I had a different experience on a Mac or Linux machine. The device flow experience is at least consistent across all platforms. When running inside Visual Studio, you get a dialog as you'd expect since you're running in a UI.

Currently, MSBuild has no concept of "prompts". The messages are simply logged as high importance messages. We could potentially add another logging level to make it a different color. If we don't care about the color, we could change the overall look of the prompt inside this credential provider. I'd definitely be behind a change to the text of the prompt as we just released it and its a good time to revisit if people have feedback.

from artifacts-credprovider.

There's also a similar issue regarding the visibility of the messaged raised on NuGet's repo. NuGet/Home#7364

So that is something that we can definitely improve.
As far as the client is concerned, currently that is a generic log message, so the easiest thing would be for the plugin to add some pretty print around it.

from artifacts-credprovider.

Adding bright colored logging around the device flow prompt is a good idea. I've added it to our back log.

from artifacts-credprovider.

Also, still I think it'd be nice to have an option to turn the dialog on from MSBuild, maybe by passing another property. So if the user explicitly chooses the dialog instead of the device flow, they can get to it, even if it's just available on Windows.

from artifacts-credprovider.

Also, still I think it'd be nice to have an option to turn the dialog on from MSBuild,

@KirillOsenkov What would the expected behavior be if you were on a Mac or Linux machine or .NET Core and we can't open a UI dialog?

from artifacts-credprovider.

@jeffkl Fall back to device flow

from artifacts-credprovider.

Tagging this as duplicate of NuGet/Home#7364.

from artifacts-credprovider.

The latest version of the credential provider has some additional attention tracking print around the device flow prompt. https://github.com/Microsoft/artifacts-credprovider/releases

from artifacts-credprovider.

Closing this as the duplicate issue is closed and we've improved the visibility of the device flow request.

from artifacts-credprovider.