Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

installcredprovider script should respect NUGET_PACKAGES env variable #89

Closed
ViktorHofer opened this issue Apr 4, 2019 · 10 comments
Closed

Comments

@ViktorHofer
Copy link
Member

See https://docs.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders

@satbai
Copy link
Contributor

satbai commented Jul 12, 2019

Hi @ViktorHofer, I just checked the NUGET_PACKAGES variable and tried it out. It looks like for NuGet to find the auth plugin, the cred provider still needs to live in %userprofile%/.nuget/plugins even if I use the the NUGET_PACKAGES variable and the packages folder isn't %userprofile%/.nuget/packages anymore. There is a chance that I misunderstood the ask, however. Please feel free to re-open the issue if I misunderstood, and explain in detail what the request for the NUGET_PACKAGES env var is. Thanks!

@satbai satbai closed this as completed Jul 12, 2019
@ViktorHofer
Copy link
Member Author

The script currently hardcodes the path to the packages folder and does not honor the NUGET_PACKAGES environment variable: https://github.com/microsoft/artifacts-credprovider/blob/master/helpers/installcredprovider.ps1#L23

@satbai
Copy link
Contributor

satbai commented Jul 12, 2019

That is the location of the plugin, not the packages folder. Was the install script failing for you? If it was, maybe the .nuget folder didn't exist? If that's the case I can modify the script to check for the folder.

Edit: just tested that - at least with Windows the script creates the .nuget folder if it doesn't exist.

@ViktorHofer
Copy link
Member Author

Right, why does the plugin need to be installed at that location? Why does nuget not try to resolve the same way as it determines the packages folder location?

@satbai
Copy link
Contributor

satbai commented Jul 12, 2019

Here's the spec on how NuGet finds the cred provider plugin. Basically, %userprofile%/.nuget/plugins is a location NuGet has chosen to look from when trying to authenticate to a package source endpoint. That's why the script always installs the plugin to the same location.

@ViktorHofer
Copy link
Member Author

Can we change that / is there a reason for that?

@satbai
Copy link
Contributor

satbai commented Jul 12, 2019

I don't think the location can currently be changed by users. NuGet specifically expects the following folder structure in %UserProfile% (from spec):

.nuget
    plugins
        netfx
            vstscredentialprovider
                vstscredentialprovider.exe
                nuget.protocol.dll
        netcore
            vstscredentialprovider
                vstscredentialprovider.dll
                nuget.protocol.dll

Although, if you need to have the cred provider in a different location, you can manually move it to a location you prefer and then use the NUGET_PLUGIN_PATHS environment variable described in the spec to point to the cred provider .exe or .dll file.

@satbai
Copy link
Contributor

satbai commented Jul 12, 2019

What we could do is add a comment to the script or update the readme and explain that if the cred provider needs to be in a different location for some reason, you can use the NUGET_PLUGIN_PATHS variable. Would that have been helpful?

@satbai satbai mentioned this issue Jul 12, 2019
@ViktorHofer
Copy link
Member Author

It doesn't look like NUGET_PLUGIN_PATHS env var is respected in the script? Was looking at the sh script.

@satbai
Copy link
Contributor

satbai commented Aug 2, 2019

That's correct. The NUGET_PLUGIN_PATHS env var needs to be set up manually. The script only installs the cred provider to the pre-determined location NuGet looks for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants