Update! This has been fixed in ProGet 4.0.6

Thanks Alana, I will have to run the install as a service account to make sure it has access to SQL. I didn't expect it connects to SQL server as it unpacks the resources. So, it didn't cross my mind that this would be an issue. I have not yet validated if the issue is resolved, but I am 99% sure it will be. I will reply to the post once I confirm it.

You can mirror ProGet feeds, but we don't have a Maven <> Maven repository option just yet.

Although we do not provide a reseller discount, we do work with quite a few software resellers who purchase on behalf of their clients, as those clients prefer to have a single source for all procurement. If, as a reseller, you purchase directly from the MyInedo portal, just contact us with the end-user information, and we will update the licensing information. You can also submit a quote request as needed.

Wow, great find :) This will be addressed in the next maintenance version.

You could use a different workflow (or in v5, "pipelines" as they will be called)... and then have a different build importer/feed on each. Alternatively, you could not use the build importer, and just have a build step download the package and incorporate it as an artifact.

npm does not support Windows Auth. Unfortunately IIS/ASP.NET does not allow for some things to be Anon, some things to be Windows -- the whole site is one or the other. Best workaround is to create two IIsSites on the site server with different ports. You can point both of them to the same application directory. Note this does not require a separate license because it's considered the same instance, and largely a workaround for the authentication problem.

If the app can't access the service, it seems like it shouldn't assume everything is OK, but rather indicate that it has no idea because it can't access the service. :)

To migrate ProGet to a new server is as follows: If you're using a local database, back it up and restore it on the new server If you're using a local package store, copy those to the new server (ideally same exact path) Install the same version of ProGet on the new server, pointing to the new database Change whatever IIS settings you desire From the web app, edit whatever settings may have changed from the Admin section

Thanks Alana, that's very useful to be aware of, I'll follow up with the nuget team as well.

It looks like the underlying error is, DirectoryServicesCOMException: A local error has occurred. It's obviously not helpful at all, but in searching for that exact text, there are so many things that it seems to be, or could be. I would suggest to search for that error and see what is relavent, and what isn't. There are so many suggestions on how to fix it, from improperly configured AD permissions to obscure 2008R2-only settings.

This is unfortunately not trivial to debug, and will require understanding/learning how the symbol/source serving work (and the arcane tools to inspect said files), since it could be any number of things at this point, from your local pdb cache to improperly build pdb files. But take a look at some of the other Q&A posts with symbols tag, specifically this one which shows how to use pdbstr.exe to inspect. If you find out specifically what the issue was, please do share it.

ProGet is licensed per server, therefore this scenario requires 2 licenses. I believe the FAQ you are referring to is for one of our other products BuildMaster that is licensed per user, which allows the same key to be used in test instances.

Unfortunately, that's not uncommon. Keep in mind the remote registry is a gigantic JSON file that ProGet downloads and then processes. What's happening is that npmjs.org is just inexplicitly terminating the connection during the download. You could be downloading it too slowly, too fast, or who knows? You can try it again, and maybe it will work. Some users have reported that downloading the file from a different network, and then hosting that file on a local server works fine.

Hi Mike, Apologies for the delay, but the problem is with the NuGet extension for BuildMaster. There is a new version (4.7.2) available that can be updated from within BuildMaster on the Admin > Extensions page.

HTTPS/Certificates are at the socket layer... below ProGet's application layer. We're not familiar enough with Bower's internals, but it's most likely just using the operating system's network stack, and reporting warnings/errors from the underlying components. Likely it's a certificate trust issue between your computer and the ProGet server, or some intermediate authority. So, while there's nothing we can do on the PRoGet side, hopefully this helps point you in the right direction.

Good question; in all package managers, a "package" always refers to unique instance (i.e. a single .nupkg, a POM, etc.). Different package managers consider uniqueness different: in NuGet, this is Id + Version in Maven, this is Group + Artifact Name + Version So, that task indicates if you can overwrite a package already added.

We don't currently have detailed documentation on all of the tasks, but it's on our list. If you have specific questions, we are happy to answer them of course! In the case of Feeds_OverwritePackage, if you do not have that task, then you will not be able to add/push a package that already exists. This is the default behavior of public feeds like nuget.org, npmjs.org, etc. -- once it's added, you cannot remove or update it.

It should "just work", but when it doesn't there are so many things that it could be. Often times, the API/libraries from Microsoft that we use to query AD simply return no results (and no error messages, either). So, you'd have to check the ProGet logs, the Windows Event logs, and Active Directory logs as well. 80% of the times, it's permissions related; i.e. the ProGet web service account user does not have permission to query appropriately.