thanks for the report; the label should say "top-level items", not "everything".

I see; have you've tried putting in your npmjs username and password in the connector? If that doesn't work, then it's not a supported scenario.

Thanks!!!!!! That will help a lot.

We'll add that as a proposed feature. I think the only issue aside from a small query/performance issue in implementation is that dependencies can change for different versions, so we'd really just be showing the latest version's dependencies there. Still, we are already doing that with certain fields like description, so that's not too bad...

The only thing that will yield this message -- The process cannot access the file '...' because it is being used by another process. -- is another process having a lock on that file. Windows does not provide information about which process that is. So, you'll need to use a tool like procmon to see file handles, and identify the culprit.

Thanks for the additional feedback! Do keep in mind that this was simply one possible work-around for a bug in the NuGet client that they fixed more than a year ago. Also do note that, when you grant a user Feeds_AddPackage to a user, they only have access to do that task. Which in this case, is very minimal. They do not become ProGet administrators, etc. In Windows, you can actually configure all users to be "Domain Administrators" (or have "root" open in Linux). We offer the same flexibility in ProGet, and you can configure ProGet to be as secure or open as needed. This is actually a very common feature in software/vendor products and, like most software vendors, we empower users to decide how secure or open to make their instance based on their specific needs and requirements. Unfortunately we can't offer specific advice to everyone on our forums on how to decide which policies suit them, but we do have some training and certification courses which offer lots of security topics (including awareness of the "security hole" you described, as well as lots of other potential attack vectors). You seem to be quite passionate about organizational security (i.e. InfoSec), which is awesome! There's a ton of great sources out there, but I would highly recommend you follow Krebs on Security and Schneier on Security. Those are some great starting points which you can use to starting learning how to develop best practices in your own organization :)

Thanks. That was the problem. After updating the Windows extension from 5.5.0 to 5.6.0 the powershell command is working again.

The admin tool does not currently add the user back; but you can do so directly in the database; the tables are fairly straightforward. To reinstall, make sure to drop the database after install well. It does not get removed by default.

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

SOLVED Human error on my part. Thought it best to state this so that others don't waste anytime on the thread.

This is a "false positive". See KB#1113: Anti-malware False Positives, Code Signing, and Safety of Inedo Products for more information. Please Report the False Positive! Please let your malware protection provider know about the false positive; the more people who do, the greater the chance they won't flag these in the future

A 401 means not authorized; so, you will want to make sure you are using proper credentials and , if you have integrated authentication configured, then it's working for the account using the NuGet push.

Aside from following the general back-up/restore instructions (database / package store / config files), there's nothing else to configure on ProGet. If you're getting errors, then something wasn't migrated properly. If a different file path is reported in an error, then a different file path is configured in the new instance; check out the error message under ADmin > Errors to see what the 500 was getting.

There is no upper limit. NuGet packages shouldn't be more than a couple megabytes; and the more zeros you add, the more you are using the wrong tool for the job, and will have problems with how the client handles local machine caching, etc. A ProGet Universal Package is designed for gigabytes, on the other hand.

Thanks for the report. We'll have this fixed in v4.5.4, which will likely be available today.

It would be nice if you could avoid this error? It's filling up the error log, making it hard to find the actual errors.

The Release & Deployment API was added in BuildMaster v5.5 so you'd have to upgrade to use it. As for the /api/json page, it shouldn't require a key to view the methods so there's a bug there and I've added that to our internal issue tracker.

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