Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

Nuget push works with local install, but not on the server



  • Our company is evaluating ProGet in order to host our own NuGet gallery. I was able to get ProGet working on my developer machine - everything worked great!

    However, when I installed on our development server, the installation worked fine. But using the nuget push command doesn't seem to work as expected. Here is what I've been able to find in about 15 minutes of looking...

    • The %ProgramData%\ProGet\Packages\Production directory contains all of the packages I pushed
    • The Packages table is empty in the ProGet database
    • The admin console lists zero error messages, and the LogMessages table is indeed empty

    I'm thinking it's a permissions issue somewhere. Below is the command I'm using to push packages to the server. Note that I've changed the package name, ApiKey, and server name where appropriate.

    nuget push C:\Temp\NugetPackages\CommonLib.1.0.1.nupkg -ApiKey [ApiKey] -Source http://servername:81/nuget/Production -Verbosity detailed
    
    Pushing CommonLib 1.0.1 to 'http://servername:81/nuget/Production'...
    PUT http://servername:81/nuget/Production/
    Your package was pushed.
    

    Is there another log file that might give me the output of ProGet Core?

    Product: ProGet
    Version: 3.1.2



  • Is the ProGet Windows Service running? If so, can you restart it? The pushing (and other NuGet API functionality) is handled by the web application, but the indexing is done by the service, so as long as the packages are appearing in the storage directory, a restart should resolve this.



  • Hi Tod,

    Yes the service was already running. I tried restarting it twice, and am getting the same result - no packages in the feed, even though there are *.nupkg files in the feed's folder.



  • And there's no package indexing errors at all?

    Are you sure you're accessing the correct URL to view the packages from the web app, e.g. http://servername:81/feeds/Production

    Note that http://servername:81/nuget/Production will not display any packages in the XML output, you'd want http://servername:81/nuget/Production/Packages() to see them in the XML.



  • Correct, zero package indexing errors. To find this I clicked the gear icon in the WebApp. It lists this on the right side of the page.

    And yes, I'm definitely using the correct URL. I am using the WebApp to get there by hovering over Feeds, then clicking Production.

    http://servername:81/nuget/Production/Packages() returns the following:

    <?xml version="1.0" encoding="utf-8"?><feed xml:base="http://servername:81/nuget/Production/" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns="http://www.w3.org/2005/Atom"><title type="text">Packages</title><id>http://servername:81/nuget/Production/Packages</id><updated>2014-08-25T19:13:51Z</updated><link rel="self" title="Packages" href="Packages" /></feed>



  • For extended logging, try stopping the service and running ProGet.Service.exe manually - this will open it up as a console window and it will run under your own account. This will also see if it's permissions related... though it should log an error if the indexer cannot read the packages directory.



  • Running from console asked me for some input, so entered 1 to Run the service, then entered the feed url that I wanted to start. It then found all of the packages and updated the database.

    However, upon pushing more packages, I found that those packages weren't updated. Once this happened, I remembered that I had to explicitly create a SQL user for the ProGet database (our server team doesn't allow local server accounts to authenticate to SQL but our domain accounts can). Once I edited the ProGet.Service.exe.config file with the correct credentials, it worked as expected.

    Thanks so much for the help and the very quick responses!

    Dave



Inedo Website HomeSupport HomeCode of ConductForums GuideDocumentation