This was removed when all the feed pages were combined (NuGet was the only feed type with an additional filter). We'll have to figure out a good way to add it back - it should be returned in an upcoming maintenance release of v4.4.

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

Do you have specific guidance on how to setup the separate site?

We refactored a lot of the user-interface code for ProGet 4.4, so this is unfortunately a regression introduced due to those changes. I've logged the issue and it will be fixed in the next maintenance release.

You can temporarily use your key for this purpose, that's quite alight. Just enter the key in, and it will activate.

Well i finally was able to publish to our Powershell feed. I updated the PackageManagement and PowerShellGet modules to version 1.1.0.0. which were released a few days ago... 12 Oct 2016 I hope this helps .

It's still on our roadmap, but it was pushed back to 4.7.

Looks like reinstall helped. Thank you!

This is a limitation of npm unfortunately; scoped packages are not included in the npmjs.org index, therefore there is no way to search for a scoped package via a connector. However if you already know the name, then it will work, and can be retrieved from the connector.

It's not an option, but your best bet to solve this would be: Bulk / Droppath Import from Disk (any packages) Feed Replication (from another ProGet server)

Thanks for the report, this is a bug in the UI, and it's missing the "/" between the "host name" and "api". We will fix in next maintence release of ProGet.

Thanks, will try IIS rewrite module for that.(

Hi Ruben, this was a regression in v4.4 after redoing the UI for the combined feed pages. We will fix ASAP in the next maintenance release under [PG-626].

That is just a "regular" COM+ that happens every now and then when doing anything with LDAP, so you an usually restart IIS, restart the server to fix it. Will send the code ASAP!

This is not currently supported nor is it currently on our product roadmap.

Well if you used "npm" as a source, and then set up that as a registry in ProGet, then it could be a source.

A 404 is expected if you visit the root of a maven api url; that is an endpoint that is not intended to be visited from your web browser, but by the maven client.

It's actually the NuGet client that is caching the old packages, you can view the (multiple) caches with this command: nuget locals all -list And either delete the files in those directories or use this command: nuget locals all -clear

Unfortunately Visual Studio doesn't support authenticated symbol servers; i.e. if ProGet sends a 401 response, there is no authentication challenge. We may be adding a feature in 4.7 that allows for "url authentication" of sorts, where you use a "obscured" url with an api key in it somewhere that will cause authentication to be effectively bypassed.

Uh, my current extensions path is C:\Program Files\ProGet\Extensions, not ProgramData. It's the Extensions.ServiceTempPath and Extensions.WebTempPath paths that are empty and ProGet is warning about. Here are the settings: And the warning: So now there's even more confusion. Should I move the Extensions directory from Program Files to Program Data? What about the ServiceTempPath and WebTempPath?