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.

Found the problem: It was an incorrect credentials at the connector.

This is handled by Release Package Variables within a Release Templates. They work basically the same, except now you can create multiple sets of required variables, depending on the template chosen at release time.

Chocolately packages are, essentially, nothing more than a powershell script that downloads and runs an installer from some url on the internet. It would be virtually impossible to inspect arbitrary powershell scripts and determine what they would download when run, and then download/proxy those installers. So, if you want full control over all aspects of the chocolatey packages (including the installers that are downloaded), you will just have to create your own based on the contents of the open-source packages.

In ProGet v4.2, there is an option right under Disk Path that says Package Store.

We just updated our server from 4.0.8 to 4.2.0 and now we encounter this problem too. After confirming that the package/version should be deleted, you are redirected back to the feed but the package/version is still there. In the log there are no errors whatsoever and the recent error log shows "There are no recent errors."

angular-cli gave me problems. It tries to retrieve dependent packages from https://registry.npmjs.org. ( https urls don't works on our dev pc's) At the moment I also configured the server with the feed as my proxy server, so at least that traffic passes over this server for all package handling. (I also have github and such) Tnx for any info you can provide Stijn

Awesome! I downloaded and verified this is fixed in 4.1 beta.

Here is a solution for you guys : We implemented two open source tools that allow using bower package-based artifacts based on Alana's previous comment. They are still in active early development, but we are currently using them in our day to day work. ##Bower client https://github.com/WoltersKluwerCanada/proget-universal-bower-client This tool is packaging bower repositories into a .upack file It can also deploy to a proget repository ##Bower resolver https://github.com/WoltersKluwerCanada/proget-universal-bower-resolver This tool is an extension to bower which resolves/unpackages upack-proget feeds as bower feeds.

See: http://inedo.com/support/questions/4487

It's hard to say... 3.6 was almost a year ago, and I know the npm api/format specification has likely changed since then. So, it could be a related to that...

RE: Retention Policies - those checkboxes are filters against the set of all packages, so if none are checked, then all packages would be deleted. Each checked box adds an additional restriction to or limits what would be deleted.

Caching is desigend to be transparent, so this is not currently an option. Of course there are a handful of ways to accomplish the behavior using a script, custom package store, package adapter via SDK, etc., would appreciate you sharing the method you use :)

I was only able to reproduce the difference in packages returned when the casing of the id was different than the actual ID of the package, i.e. for jQuery: http://proget/nuget/Default/Packages?$filter=Id eq 'jquery' and http://proget/nuget/Default/FindPackagesById()?id='jquery' The Packages endpoint does not return remote packages because searching in this manner is case-sensitive, while it is not for FindPackagesById. The solution seems to be always use FindPackagesById, or use /Packages?$filter=tolower(Id) eq 'jquery'.

Hi, This is an old thread but i have the same question. We're on 5.3.17 and have used up all of the space on C:\. We have 1TB on D:\, so I just want to move the PackagesRootPath to there. Does the above pattern still apply? thanks max

Actually, one more comment re: this. It appears that the package ID is synonymous with its name. I thought there was a separate ID value. When I grabbed all packages and versions and tried to serialize in PowerShell, it failed due to the size of the content, so it was good to discover that I can query for the specific package name/ID.

You may be best asking this on NuGet forums, as this relates to behavior in the nuget.exe client. We do not use "nuget.exe pack" ourselves (instead, we opt to use the proget client tools) as it's more reliable and has defined behaviors.

The story continuous :) Because I set TeamCity to create source packages as well (it's a checkbox called: Include sources and symbols) it was overwriting the packages in ProGet (I have all the PDB and sources in my nuspec files as well). This was causing the issue with the config file being gone, because TeamCity strips those files out for the symbols packages. So... I was doing things twice... Must be user error ;)

Regarding the first error – that sort of thing should only happen if the connector returns invalid data. What is the URL of the bower connector? For the registration, it looks like it’s just an HTTP 401. See this article for info about Bower & authentication in ProGet: http://inedo.com/support/kb/1095/introducing-bower-support-for-proget