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.

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.

I had to change 2 things when I had this problem on my windows computers. 1: I could not use the ip-address because of SSL errors - I had to use the host name. 2: I had to make sure that I logged on to the correct port. Your example was 88 in both login and push, but I forgot to use the port in the login command (I was using port 443). Perhaps this will help someone having the same issue.

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

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.

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.

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

To downlad a package, you'd need to use the feed-specific API (NuGet, npm, etc). The SDK is really only designed for building extensions.

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.

Discussion should be moved to a new post or followed here: http://inedo.com/support/questions/6554

I ran into the same issue when trying to run image on docker on windows (in linux container of course). First thing that I tried was to turn off proxy server. After that, instead of seeing an "Activation completed" message, activation request never finished. In the end I restored original proxy settings (same as system), restarted docker image and activation went without any issue automatically after restart.

If you are getting a browser pop-up authentication (as opposed to a ProGet login screen), then it means Windows Integrated Authentication is not working. This is due to configuration of your server or domain. Unfortunately, this is performed by IIS/Windows (not ProGet), which means the request is never reaching our software; this means we can't provide any information about why it's not working. But this also means there are a lot of resources/articles you can find to give debugging on how to get it to work. I would suggest searches like, "Windows Integrated Authentication always authenticates" etc. Please post what you find!

I found this thread after experiencing a similar issue. I was seeing the "string is not a valid semantic version error" from Proget when npm would try to install scoped packages, but only when the npm install was automatically triggered inside Visual Studio by a change to the package.json. We already had the latest version of Proget with the change to the web.config and installs worked fine when running from command line. Problem turned out to be the fact that Visual Studio 2015 had installed it's own copy of the npm.cmd as an external web tool. This was an older version than the one I had installed globally, but the order of external web tool locations in Visual Studio had the path to the older version listed before my system path. Making system path take precedence solved the issue. [image: 0285.tools-options2_15477577.png] Just thought I'd post this here in case anyone else with a similar issue stumbles across this thread like I did.

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

Currently the license filtering is only supported for NuGet-feed types, but we are planning on a license management module coming soon that will handle this much etter for npm and other feeds.

This regression was fixed in ProGet v4.5.0. I'd recommend upgrading to the latest version.

It's likely that the user installing does not have the ability to access the database defined in the configuraiton files on disk. So, make sure to run as a user that has DBO on those databases.

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

When you un/re-install ProGet, it will not delete the database unless you explicitly say to. If you run the service interactively (just run the ProGet.Service.exe), there is an option to reset the admin account permissions.