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?

Please refer to the High-level Architecture Diagram to see the components of a ProGet installation. The Database is a SQL Server database. The Web and Indexing Nodes are both .NET application that interact with the database using the standard SqlClient API. The connection string you specify in the configuration file is assigned to the ConnectionString property of that API. All of this is very standard, but it's very likely that your DBA/Network Admins configured the SQL Server you wanted to use in such a way that a simple/intuitive connection string was not sufficient. Maybe they used a special port, security, etc.; they would be much better suited to answer your question about why it's so complicated :) Also, please note that the ProGet Installer will create/update the tables and object in the database. ProGet itself does not modify (nor have the privileges to modify by default) the database structure. If you wish to install the database component outside of the installer, then you will need to follow the Manual Installation Instructions.