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.

Yes, that's the directory used by the "local agent", for the buildmaster server.

thx for the guidance

Hi, great question; yes, that would be doable through the API, but we're still putting the final touches on that. The "full API" would necessarily expose the entire complex model that's used behind the scenes (e.g. differentiating between jobs, job templates, and executions, etc), which from our experience is a real pain to work with, because it requires you to become experts of the domain model. Then you have to authenticate to it, etc. So, perhaps we'll also have a more intuitive API that looks a lot more like the web interface, and exactly like you said, has a simple url for a "kick me now" button of sorts. In the mean time, i'd definitely check it out to see how close it is to your requirements, and we would be happy to work with you to get a PoC going. It's still 1.0, but that's how we improve and get to 2.0 and so forth :)

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.

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.

Are you sure the requests are actually leaving your desktop? Obviously The Real WTF here is doing ONE THOUSAND outbound network requests for a contiguous operation. Since they managed to write a client that does that, I think there's no chance that they can competently build a proper network request pool, let alone one that reports proper messages. The NuGet client had a problem with this a while ago, where it was doing similar nonsense that lead to race conditions that only appeared when you used ProGet b/c the requests were being served significantly faster than NuGet.org.

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.

This could be a bug, or a configuration issue, or maybe even both... but we can definitely help you to resolve this. The Q&A may be challenging for this particular issue, so please submit a ticket so we can better work together on solving this!

Good point; we can add a note to the guide to consider those when you migrate/backup a server. But, it's very easy to do; just copy whatever you have in the extensions folder (i.e. one with .bmx files), and copy them to the new server's folder. Then, restart web app and service, and it will function the same as if you had just downloaded them from Inedo.com

So, in the free version I can't clear cache?

Do you mean from the ProGet UI? There is not currently such a feature.

Make sure that the service has started; if it's not, then investigate the windows error log to see if anything in there occur when you attempt to start it. Make sure there are no firewalls, or other tools are preventing access from that port being accessed.

Not as of 3.8, but there will be a UI refresh in v4.0 (due later this month) and that will no longer be in the navigation bar.

Note that you will need to specify the "Urls" argument when running the service, to indicate which url you intend to bind to.

The feed clean-up writes logs to the database before starting, so if you have no space left on disk, then you can't start a clean-up job.

This is actually a fairly common requirement with BuildMaster, and we have a lot of users who implement this in a lot of different ways. Here are the main two approaches. Different Versions for Different Customers If there is a possibility that customers will want to receive different versions of your application at different times (e.g. they may coordinate an upgrade), then the best bet is to set up an application for each customer, and then "import" the deployable from the main (customer-less, or standard) application; you can use a "controller" application of sorts to automate the build/deployment of these customer applications, or use the api. This approach will also enable "quasi-custom" software, and let you build customizations on top. All Customers, Same Version, Always If this is the case, then this is simpler on the administration side, but it can be a bit tricky on the implementation side, as there are several challenges. First, you will need to deal with the problem of adding a new customer; maybe it's not so bad, and you can do a manual copy; if you are adding several customers a day, maybe it's a problem Then, there's the problem of rollout; do you take down every customer site at once, then upgrade, then turn them on? Or do you do a more rolling strategy (one at a time), (five at a time, etc) What about failure, such as if customer 33 of 58 has an error during upgrade? Do you continue with the rest, or stop the whole process It's hard to advise on a general approach because of these considerations. There's also scope and scalability -- are you looking at a handful, dozens, or hundreds of customers? Regardless, I would look to the features in the new execution engine, as they will simplify this problem quite a bit: If you are frequently adding customers, then this is more of a "configuration management" problem, and Otter may be a good fit for the delivery aspect You can create custom "Variable functions" that will allow you to use external data sources (CRM, etc) for customer lists. then you can do something like <pre> for each $customer in @GetCustomers() { if $ShouldDeployCustomer($customer) { ... } } </pre>