The Visual Studio 2022 17.14 update is here, and it brings great quality-of-life improvements—especially around NuGet authentication. From context about the authentication needs of private NuGet feeds to a simplified account selection workflow, this update helps you stay focused on your code! If you haven’t already, download the latest Visual Studio update to take advantage of this and the rest of the improvements.
Streamlining the NuGet authentication experience
Over the past year, we’ve made significant strides to improve the identity and authentication experiences across Visual Studio 2022. For instance, we introduced Web Account Manager (WAM) support to unify and simplify the sign-in experience of Entra ID accounts & we recently followed that up by adding multi-account support for GitHub, making it easier than ever to manage your GitHub identities inside Visual Studio.
Today, we’re excited to share the next step in that journey: a more intuitive and reliable NuGet authentication experience. With the latest update, Visual Studio now proactively detects when authentication is needed during package restore and presents a new dialog that provides helpful context—such as which feed you’re attempting to access—and makes it easy to select the account best suited for the job. This small but impactful change simplifies the sign-in process, reduces authentication prompts, and helps you stay focused on your coding needs.
Here’s what you can expect:
- Clearer sign-in guidance showing you the specific NuGet feed you are accessing.
- Improved support for multi-factor authentication (MFA) allows you to efficiently manage accounts needed for NuGet restore operations, whether adding new accounts, selecting from existing ones, or re-entering credentials directly within the dialog.
- A more predictable sign in experience, with fewer repeated prompts and less authentication guesswork.
Try It Out and Keep the Feedback Coming
We’ll continue investing in making the Visual Studio’s identity and authentication experiences more seamless, secure, and intuitive so please, keep the feedback coming— Every suggestion, upvote, and report helps us prioritize the areas that matter most to you. And while we’ve made great progress, we’re far from done!
Ruben, what about the CD/CI experience? The NuGet feed authentication flow there is extremely convoluted today, with the need for the custom credential helper and the use of that long environment variable (I forgot the exact name) where you have to provide a json object with the feed and the PAT token that keeps expiring and needs constant refreshing.
It would be really nice if that experience could be streamlined as well.
I work on NuGet, and I'd like to reiterate Ruben's request that you create feedback on either NuGet's issue tracker, or the VS/Azure DevOps Developer Community feedback system.
Reading your comment, I don't understand your scenario. For using Azure Artifacts, it should be "as simple" as using the `NuGetAuthenticate` task, and then you can use `dotnet restore` and `dotnet push` in script blocks and it should Just Work. If it doesn't, then we need more information, although NuGet doesn't own the `NuGetCommnad` or `DotnetCoreCli` tasks, so I recommend running dotnet, msbuild, or nuget.exe directly in script blocks, so the exact same...
I’m not able to reply to your last comment but wanted to say that while I can’t promise anything, I reached out to the NuGet team to try and find someone to talk to this. That said, its likely that they will ask you to log a new issue on GitHub.
Thanks for sharing your feedback! Are you referring to the CI/CD experience in Azure DevOps? If so, please log a feedback ticket under the Azure DevOps channel on the Developer Community portal. That’ll ensure the right teams see it.
No, I’m talking about NuGet feed authentication when run via dotnet CLI on CI/CD pipelines in general.
But I think the way you answered makes it clear this change doesn’t touch any of that. Unfortunate.
Honestly, it would be more helpful to have a centralized nuget experience. Having custom upstream sources with enterprise environments/credentials is more required but this request is open since 2018: https://developercommunity.visualstudio.com/t/custom-public-upstream-sources-in-nuget-package-ma/366068.
I’m not able to reply to your last comment but wanted to say that while I can’t promise anything, I reached out to the NuGet team to try and find someone to look into the status of this ask.
Hi Martin! I took a quick look, and it seems like that request hit a tough spot right after being added to the roadmap. Unless I’m missing something, I don’t think the ticket is in the right location—it seems better suited for the Azure DevOps community rather than Visual Studio.
If that’s the case, I’d recommend creating a new request under the Azure DevOps channel and linking back to this ticket. That should help ensure it reaches the right teams.
Hi Ruben. As you can it is already been “Migrated from Azure DevOps UserVoice forum”. Opening a new one is a bad thing because we would loose the votes, which are currently ~269 which is not a small number. Opening a new ticket would reset the counter to 0 which does make this request smaller as it is.
It would be better if you or someone from MS would migrate it back to the devops channel.
This is great. Prior to this I had been getting too many pop-ups whenever I open my solution. I have multiple repos with multiple Azure Dev Ops accounts. At the moment, this new popup comes but very less frequently.
Glad to hear this update has made things easier for you! We’re discussing more improvements, so if you have any ideas or feedback, please drop a suggestion on the Developer Community portal!