Please note the privilege changes in v4: Upgrade Notes for ProGet 4.0

Hi Luke, you'll want to put the connection string in quotes: bmdbupdate UPDATE /conn="Data Source=DB1;Initial Catalog=ProGet;Integrated Security=SSPI;User ID=Account;Password=Password;" We'll try to add that to a new version of the database updater! Cheers!

I get the same issue with v4.3.1 (Build 5). With nuget, I can search (via connector) to list all packages available on nuget.org. But with npm, unless I manually add packages via npm connector, the search shows a blank page.

This isn't specific to ProGet at all, but HTTPS/SSL in general. It's not possible to bypass or address this from the server software (ProGet) side at all. You'll need to either trust the self-signed certificate on the client (Jenkins), install a certificate from a trusted root (server), or bypass that warning in the client (Jenkins).

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.

It sounds like ProGet is working fine, but that the CHOCOLATEGUI doesn't support Windows Integrated Authentication. I would submit a ticket/bug request on their github and ask them to support it. It's generally a relatively easy change to make, depending on how they implemented querying.

Hmm, I wonder if it's related to Powershell Execution Policy? I'm not terribly familiar myself, but I know I've had to fiddle with that a bit to get things working... 15 Ways to Bypass the PowerShell Execution Policy

Looks like a bug caused by accessing certain pages from clients that don't support gzip compression. We'll have this fixed in 4.0.15, which should be released today.

In this case, the error message means that the user runnin the installer does not have permission/access to read the configured ProGet database (this is an upgrade).

There are several ways to solve this problem, but a common approach is to multiple servers in each global location, and then either use connectors or replication to ensure the packages are accessible locally.

You could create a connector of this feed and add it to the other feed, so that you don't have to do any manual steps. It would act as remote connector and pull packages directly.

When you download a package, then package is cached by default; if you download aggin, it will use your local cache instead of re-downloading from npm. The caching is transparent, so they will not show up as local packages.

This is a bug in the free edition; we will resolve it in the next mainteannce release of ProGet.

Are you able to do this from the Admin > All Settings button? There should be a checkbox to enable load balancing. Also, FYI -- as an enterprise customer, don't hesitate to fill out a ticket or email us at support - Inedo - com, and include a couple screenshots or more info so we can better help resolve. This Q&A site tend to get a lower priority, so we may respond slower!

Thanks for your response. I'm glad to see that this will be fixed in the next release. For the time being, could you please specify which URL individual users should use, because every URL I've tried so far results in a SecuredTaskDeniedException

This may be fixed in a new version of ProGet; however please note that in NuGet 3.4 client, they added framework monikers abbreviation ("net" instead of "net45") that seem to be occasionally used. These will be supported in the next maintenance release of ProGet, udner PG-560 (Add Support for new NuGet 3.4 Framework Abbreviations).

In my original example that I used, the web user did have permissions. In fact, the user I used was the admin user. I did both create a special user with delete attributes and test the admin user. Both results were the same. Success was reported, but the package never really was deleted. I'm not using a feed APIKey, I'm only using users that have appropriate rights to do certain things, like delete.

It was most certainly permissions related. From the 4.0 Upgrade Notes... If you modified any of the default roles but did not rename then, then they will renamed to the new task names. In addition, the role's individually-securable actions (formerly, "tasks") will be reset to the new, default definitions

Thanks Alana. Could you guide me to-what table should I be making what changes?