In this case, you are pointing PRoGet to a SQL Server on a different machine. You will need to either use a different connection string (name/[assword), run proget service/web under a domain account and continue to use integrated auth, or allow connections from that machine in SQL Server (not recommended).

Solution found, wrong app pool user. thks all

Alana- looks like this one is actually on me, the reverse proxy was stopping the single quotes. But, the extra trailing slash is what causes the issue with Packages(), same as it does with the earlier problem. I have it sorted out now.

That's what the nuget.exe client does, a Delete method. Yes. That will also remove package from disk and metadata.

The resources are embedded in the ProGet assemblies (in this case, InedoLib.dll), so if you can hit the site, then it means some IIS setting is preventing those from being served. It's hard to guess which one... perhaps URL filtering?

I've updated the proget plugin to support pipeline script. It hasn't had a lot of testing (PC died and haven't had a chance to fully rebuilt it yet) but the changes were minimal so should be fine. It's also built against the latest LTS of Jenkins so I hope that won't be an issue for you. I'm also trying to do the same with the BuildMaster plugin but that one is proving to be harder to do and I've had to raise an issue on the Jenkins mailing list.

Thanks for the good news!

A License Key is always required. You can get one from My.Inedo.com. The ProGet Silent Installation guide gives the arguments to the installer; one of the options is to automatically request a key (just set Edition to Express or Trial).

The "Pull from Another Repository" actually requires the Feeds_PullPackage privilege; so make sure to grant anonymous that as well. Then it should work as expected!

Restating the Proget's service fixed the problem! Thank you for your rapid response :) Regards.

Thanks for clarifying that about the Nuget feeds. Awhile back I understood the behavior had been changed so new Nuget feeds did not function the same way. It was a discussion related to Jenkins so I may have misunderstood where the change was.

You can just drop your npm packages in the configured drop folder; they need to be valid npm package,s which means <name>-<version>.tgz file format.

Correct; that, and the API key, are what get sent over.

I trying http://myExample.com/nuget/Default to http://myExample.com/myframework/packages . But i changed baseUrl = http://myExample.com/myframework/packages/nuget/Default

My best guess is that it's related to permissions- most likely the user account which is running the service cannot talk to the SQL database. There should be an error/exception in the Windows event log if this is the case.

We actually haven't tried using SBT just yet (in fact, I just learned about it from your post). But generally speaking, one of challenges with Maven is that it's convention-based, and doesn't have any documentation on the convention. So it's possible that SBT is using a slightly different convention than Maven or Ivy clients are. Moreover, different "packages" have a convention to behave differently... Would you able to attach Fiddler and see where some of the discrepancies in the request/responses might be? Sometimes it's incredibly obvious, and that might allow us to implement yet another undocumented convention. It may be easier to communicate over email, so perhaps fill out a ticket or just email us at support-at-Inedo-com once you have some details?

You can just use the license key on the new server.

For completeness: An alternate approach is to create a private source server and update to both the source server and to the Universal Feed from out in-house deployment tool. But we were hope that we could have pig-backed on what you already had. Oh well. Thanks.