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!

[ProGet] Pushing a package to a feed using the command line



  • I am trying to push a package to a feed via the command line with a nuget.exe v2.0.

    .\nuget push ..\build\MyPackage.1.0.0.0.nupkg -ApiKey e08c2ce5-9a2c-4382-89db-06d08a90fe37 -Source http://nuget.mycompany.com/nuget/MyFeed/

    NuGet.exe returns with the error messages:
    "Failed to process request. 'OK'."

    Any ideas?



  • Hmmm, it looks like there's an issue with the PUT redirect handling. The nuget.exe client should be redirecting to the "API Url" instead; the feed and api url are two different things in the NuGet world... anyway, we're investigating now.

    Can you try going to the API Url directly? Just replace the source paramater with:
    http://nuget.mycompany.com/api/v2/package/MyFeed/MyPackage/1.0.0.0



  • This issue has been addressed in ProGet 1.0.4.



  • Thank you for the quick release.

    I've upgraded to 1.0.4 and now I get a different error message: "Failed to process request. 'You are not authorized to add a package to this feed.'.
    The remote server returned an error: (403) Forbidden.."

    When using the nuget commandline, I don't think it's possible to specify any credentials.

    Any ideas?



  • You are correct; NuGet .exe wants to use an API key., not credentials. You can, however giveAnonymous User privileges to publish packages, or use LDAP authentication.



  • I created a 'Publisher' role with permissions Feeds_AddPackage, Feeds_DownloadPackage, Feeds_ViewFeed and granted the privilege to anonymous and that worked. I see the packages in the feed directory on filesystem.

    I have 2 feeds - one I push my internal packages too, and another that has a connector that caches a feed from myget.org.

    When I try to install a package from either feed:
    .\nuget i MyPackage -Source http://nuget.mycompany.com/nuget/MyFeed/
    ... I get an error : "The remote server returned an error: (500) Internal Server Error." There is no further information regarding this error. Are there any logs anywhere?

    When I browse the feeds and try to download a package directly I also get an error 500.

    Btw the feed directories are on a network share.

    A suggestion: When browsing a package in a feed, it would be nice to see a list(and be able to download) of the previous versions, perhaps under Release Notes & Dependencies.



  • Are you using the latest version of ProGet (1.0.5)?

    There was an issue with parsing non-.NET version numbers (like 1.2.4.a or something), but this was resolved. You should also see the specific error message on the browse packages page.

    Also --- great idea, we'll add that to the list.



  • On 1.0.4, will upgrade to 1.0.5 and verify the problem still exists (or not)



  • Issues still exist on 1.0.5

    I have 2 feeds, one feed name has spaces in it and when download via download button ( http://nuget/api/v2/package/Approved+3rd+Party/Rx-Main/1.0.11226 ) get an error 500 "There is a problem with the resource you are looking for, and it cannot be displayed."

    On a feed we that doesn't have a space in it, we get "File not found

    FireFox can't find the file at http://nuget/api/v2/package/MyCompany/Rx-Main/1.0.11226.

    • nuget is the host name alias we've given to proget
    • our packages are stored on a network drive. Uploading packages writes them to the network drive, and they appear in the feed browser, so I don't think we have a permissions problem here.


  • The "space in a feedname" is definitely a bug; will get that fixed in next release.

    As for the cannot download file, that's strange. Is this for all packages (even connected ones)? Can you download from visual studio? Another browser?

    If it's letting you browse to the package, it's reading it from a .nupkg file, so it's curious that browsing would work but transmitting the file wouldn't.



  • (FOr some reason, I didn't appear to get email notification of your reply...)

    On 1.0.6, can confirm the space in the feed name bug has been fixed.

    Our feed paths are on a network share in the form of an unc path i.e.: "\storage\Proget\Feed". Attempting to download a package from these feeds results in the error "Error 6 (net::ERR_FILE_NOT_FOUND): The file or directory could not be found." in chrome and "File not found. Firefox can't find the file at http://nuget/api/v2/package/Feed/7Zip/9.20.0.0."

    This doesn't look like the usual 404.

    I've just created a test feed and left the Feed Path default to "C:\ProgramData\ProGet\Packages\Test", uploaded a package and can confirm that it downloaded without a problem.

    Going to setup a mapped network drive to see if that makes a difference. Will report back.



  • Ran some further tests:

    1. Network share UNC path: Able to browse the feed, upload package via UI (which writes the file), cannot download.
    2. Mapped network drive: "Could not find a part of the path."
    3. SymLink in C:\ProgramData\Proget\LanPackage => network share: Able to browse the feed, upload package via UI (which writes the file), cannot download.
    4. C:\Temp: Able to browse the feed, upload package via UI (which writes the file), cannot download.

    In fact, the only way I could download a package was if the feed path was in the default location of "C:\ProgramData\ProGet\Packages\Feed"

    Tried to download with chrome, firefox, and nuget.exe.

    Seperately...
    In addition, when browsing a package in a feed, the instruction to install is this:

    PM> Install-Package AutoMapper

    perhapes include a command line version?

    PS> .\nuget.exe i AutoMapper -source http:\feedurl



  • Thank you for the detailed analysis. We have confirmed that the behavior you are experiencing is a bug related to the default package root path in advanced configuration vs. the feed override path. It will be fixed in the next version.



  • Ok thanks. I await the new version.



  • Any word on 1.0.7?

    Also, any reason there are no timestamps on these Q&A replies?



  • We are still working on 1.0.7 and plan on releasing it sometime this week.

    As for the timestamps, we do store them and will likely update the site to display them at some point.



  • For your reference, we have released v1.0.7 of ProGet today which resolves the package path handling issues.

    Thank you again for the report and for your patience!



  • Installed 1.0.7, and no issues to report with our network share backed feed.

    Thx.



Inedo Website HomeSupport HomeCode of ConductForums GuideDocumentation