Hi @daxian-dbw, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Dongbo Wang). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

@lzybkr can you please review this PR? Thanks!

The Credential parameter set is the default parameter set, and -Credential is the only mandatory parameter in that parameter set, so it's natural that the parameter binder will kick in prompting for the missing mandatory parameter -Credential when no argument is specified.

Of course - but I'm asking a different question - can we get the same effect of prompting in Get-Credential without relying on the parameter binder?

For example, if we changed the default message/title in Get-Credential, we'd also want a similar change in the parameter binder. I don't think that's obvious or ideal.

But really - I'm just saying we should be seeing the parameter binding prompts when asking the user for a credential. Ever.

Got @lzybkr 's point now. The current change gives inconsistent prompting experience for Get-Credential and Get-Credential -UserName bar. Note that the default caption and message are not displayed for Get-Credential

PS D:\> Get-Credential

cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
Credential
User:
PS D:\>
PS D:\> Get-Credential -UserName bar

Windows PowerShell credential request.
Password for user bar:

This is because for Get-Credential, the prompting comes from the parameter binder, while the other comes from Host.UI.PromptForCredential. I will update the PR to provide consistent prompting experience.

@daxian-dbw Please take a look #2315

I approve this fix 👍

But why not move the last writeobject to the try ?

try
{
    Credential = this.Host.UI.PromptForCredential(_title, _message, _userName, string.Empty);
    WriteObject(Credential);
}

@McAndersDK it's to avoid a very very rare edge case -- WriteObject somehow throws ArgumentException. If that really happens (unlikely), we should allow that exception to propagate and be handled by the engine.

@lzybkr The PR has been updated to address your comments. Please take another look when you have time. Thanks!