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.

If access is granted, then ProGet will routinely perform update checks. The url is http://inedo.com/pg. No specific package information is sent. If you block the outbound ports, then update checking will not be done. You will also have to activate your license manually. A lot of organizations do this; it's fine, but slightly less convenient.

The issue turned out to be a problem with uploading the package to ProGet. ProGet was reporting the package was available in our feed and we were able to download the package through the website however the package was not available through the nuget feed. Deleted and re-uploaded the package a couple times and it finally took. Issue resolved thanks to help from Inedo's great support team! Thanks!

That error message is coming directly from your remote SQL Server, and it can mean several different things: wrong password is specified for sql_tg_proget on that server the tg_proget database does not exist on that server the sql_tg_proget user does not have access to tg_proget on that server SQL Authentication is disabled on that server, or another setting is preventing the application from logging in to the database using that name/password; for security purposes, SQL Server does not log these reasons to the client In this situation, your connection string needs to be modified to either point to the correct server, and/or use the correct username, password, and database, or the sql server needs to be configured to permit that connection string. There is no other configuration required (or even possible) on the application side to connect to the database. Only the connection string.

Just use the API/Feed endpoint that you would otherwise use for that feed type as a connector.

Hi Stuart Could you let me know the settings you're using in the upload proget package build step in your Jenkins job and if you've changed any of the default settings in the advanced section of the build step? I've not been able to come up with a combination that causes an exception to be thrown in UploadPackageBuilder.java. Regards Andrew

Take a look at Changing an Inedo Product's URL with the Integrated Web Server; after setting up a certificate, you can follow this guide to register https urls, and edit the configuration file to listen on port 443 for ssl.