nuget.exe 1.6 credentials never accepted (now fixed in 1.7...but:)

Feb 29, 2012 at 5:31 AM

Hi folks,

I have a nuget 1.6 server running our own package source as per the documentation. The server is running on IIS6 over SSL with AD domain authentication.

Everything is working fine from the NuGet package manager or when viewing packages in a web browser, however I am running into problems with nuget.exe. I am doing this using the new package restore feature.

If I try nuget.exe sources it shows our package source as enabled with the same URL that is working in the package manager and browser.

If I try nuget.exe list it prompts for credentials to authenticate, but never accepts them.  I have tried both domain\user and user with no luck.

If I try a MSBuild from a clean checkout, I can see it's not specifying the source or passing or requesting credentials:

RestorePackages:  "D:\foo\.nuget\nuget.exe" install "D:  \foo\bar\packages.config" -source "" -o "D:\foo\bar\packages"  Please provide credentials for:  UserName: Password:
EXEC : warning : Cannot read keys when either application does not have a console or when console input has been redirected from a file. Try Console.Read.

Before I raise an issue, is there something basic I'm missing in how to set this up?  nuget.exe version is 1.6.21205.9031.

Do I need to save my (hopefully encrypted) credentials somewhere? I couldn't see anything in the docs about specifying -Username or -Password options. Note that our goal is to have package restore baked into our release process on our build server, which is authenticated through a domain service account. Hopefully that's doable.

Thanks in advance for any help,

Feb 29, 2012 at 4:03 PM

We added support for storing credentials in the 1.7 release, however you shouldn't have to provide one in your case. Could you modify your push to point to and see if that works?

Feb 29, 2012 at 11:14 PM

Thanks for the reply Prana.

I tried appending .../api/v2/ to the URL and get a 404 in package manager and "Resource not found for the segment 'api'." from web browser.

Perhaps a clue I haven't got something configured correctly on our nuget server?

Feb 29, 2012 at 11:25 PM

My bad. The url's (basically <siteroot>/api/v2).

Mar 2, 2012 at 5:38 AM

Still didn't work.

However, I tried a build locally (we have everything stored in subversion) and nuget.exe via MSBuild did work from the nuget server on my own dev box (Win7 with IIS7 no SSL or AD), so it's something related to our Win2003 server, IIS6, SSL or AD authentication :)

We're only experimenting with nuget at the moment, and I ran into some issues with package restore from a clean checkout and build (for content files, not lib references) , so I'm happy to keep learning/testing and wait until 1.7 is released and then try again on our proper server.

Apr 13, 2012 at 7:02 AM

Ok, just tried the 1.7 version of nuget and things are working a lot better, thanks!

I can now use the default URL from our SSL encrypted domain authenticated IIS6 server. However, I hit one hurdle and one roadblock still remains.

First the hurdle: after updating the NuGet.Server package, I went back into package manager and noticed that updates were available for Ninject, WebActivator and RouteMagic. Whilst WebActivator and RouteMagic appear OK, Ninject version 3 doesn't work with NuGet.Server. This is the exception thrown. So I would humbly suggest someone from team NuGet confirms this problem and if so locks the maximum Ninject version for NuGet.Server.

Now the roadblock: the only way I could get package restore to work successfully from a clean environment, i.e. no previous builds and no packages installed, was to explicitly set the -Source option.  However, the default option from a standard build (such as MSBuild foo.sln) seems to always passes -Source "".

If I took the nuget command line directly from the MSBuild output and changed -Source "" with -Source "" and ran it separately, then I get prompted for credentials and the packages are restored as expected (yay!). So it's very close to working. I tried manually setting the solution's .\nuget\NuGet.Config so that it contained the package source:

		<add key="disableSourceControlIntegration" value="true" />
		<add key="Foo package source" value="" />

However that still passed an empty -Source "" when called from MSBuild target.

So does anyone have any clues as to how to resolve this?

thanks in advance

Apr 13, 2012 at 4:11 PM

I think we have a bug when it comes to reading the packageSources value from the local nuget.confg file. But for now, you should be able to specify the sources in your NuGet.Settings.Target file (there's a PackageSources Property that accepts semi-colon separated value) which should work.

Apr 16, 2012 at 2:55 AM

Thanks again Prana, adding /p:PackageSources=... worked, so that's fine as a work-around.

There still seems to be a problem with entering credentials from msbuild target, it works from nuget.exe but when I invoke msbuild it just sits at "Please provide credentials for:...".

I guess we have to cache credentials as msbuild probably won't accept manual input, and regardless we would want to automate this on our build server.

I checked the nuget.exe help and couldn't see a way to save credentials or enter them via nuget.exe command line or msbuild properties?

Apr 16, 2012 at 4:07 PM

We added a a way to store credentials with sources in 1.7. I need to get the documentation up to speed with it, but you run

nuget.exe source Update -Name <name> -UserName <username> -Password <password>

The credentials are encrypted (using DPAPI the same as your APIKey) and stored in the nuget.config file in %AppData%\NuGet