While the "switch to LDAP page" should not allow changing directories if it's not configured properly, most likely the BuildMaster server is unable to query ldap.

While there is currently no first-class extension for it, it'd be really easy to do with a Execute Command Line action, or a reusable Powershell Script that you put in the Script Repository. It's also fairly easy to write your own extension too -- if you choose to go that route, let us know, and we'll be happy to help where we can!

Thanks for letting us know. At some point, we switched to doing connector searches in parallel, so the ordering was no longer consistent for identical packages. It seems to be an easy fix though, so it should be working again in 3.5.6, due out this week.

It looks like the timeout box is not being rendered for some reason. We'll be releasing an update this week for ProGet which will include a fix for that. For now, it is possible to set the timeout either directly in the database or using the API. If you have access to the SQL instance, probably the easiest thing to do is change the Timeout_Period value for the connector (it's in seconds). You can get the connector ID by looking at the URL for an edit connector link. After setting it, you'll probably need to restart the web site by going to the All Settings page and just clicking Save. Sorry about this- we haven't needed to change the timeout period for a while. As far as the poor performance goes, I imagine nuget.org simply is not optimizing anymore for the types of queries that our connector filters are using. If there's nothing simple they can do on their end, we'll figure something out, but hopefully it's just a temporary issue with them.

This is related to the timeout question, so I've posted the answer there -- http://inedo.com/support/questions/2915#inline-post-2936

You can disable the View privileges from Anonymous user, otherwise you'll have to upgrade to the Enterprise edition (a free trial is available) for more specific, feed-level privileges,

Thanks for the investigation- we'll see if we can get this configurable in the next release, and possibly look into seeing if we can avoid clobbering web.config on upgrades.

Hi Byron - We do have a number of BuildMaster users who utilize the "Attach Build Report Action" to capture the output of a Fortify Static Code Analyzer scan after running it via the command-line; it's a general-purpose Action that will basically attach the report to the build so that everyone has visibility on the scan. Others will use Coverity for static analysis in the same manner. It would be relatively easy to build a "first-class" extension for Fortify, and as an enterprise customer, we'd be happy to work closely with you develop one should you want a bit tighter integration. Cheers, Alana

Hi Keith, ProGet is pre-configured with a Connector to NuGet.org -- just go to Admin > Manage Feeds, and then delete the connector.

Thanks, I'll wait until the fix is released. It's not a blocking issue for me.

The discussion for this question is here: http://stackoverflow.com/questions/29254068

All dependency resolution is handled by the NuGet.exe client, here's how you do it: https://docs.nuget.org/create/versioning

I had mistakenly stopped the ProGet service after I switched to IIS hosting mode, so that caused the problem.

Answering my own question using this solution. Hope anyone else who has to do this with Ruby will find this helpful: require 'rubygems' require 'httpclient' #latest, with rubyntlm also installed http_client = HTTPClient.new http_client.set_auth(nil, '<domain>\<username>', '<password>') local_file = File.new("C:\\temp\\<package>.<version>.nupkg", "wb") local_file.write( http_client.get_content("https://<server>/nuget/<feed>/package/<package>/<version>") ) -/- flagellum

Okay, Alana, thanks for your help. We will do just that.

UPDATE: This limitation no longer exists in BuildMaster v5 (OtterScript) Plans. There is no limit to the number of executions that BuildMaster can run in parallel; however, only a single remote action can run on the same remote server/agent at a time. This means that, for example, if you create a build of multiple applications at once, and all of them build on the same build server, only one of those applications will be built at a time. You can improve this behavior by using server pools if you'd like if you have multiple build servers you would like to utilize. In exceptional cases, you could install multiple agents on the same machine (on different ports), and put those in a server pool.

I've figured out what I would like to see and its an approach I've seen other tools take. I think you need a BuildMaster plugin for Jenkins that I can add as a build step in Jenkins to: Import ReleaseNumber as a variable Trigger a BuildMaster Job and a) send selected artifacts to BuildMaster, b) set the BM build number to the Jenkins build number (I just like to keep things in sync for traceability) Workflow SVN Commit -> Jenkins Build -> BuildMaster: Import Sent Files I'd then deploy to first environment (using the BM post build step action) which would do the deployment and then call test job in Jenkins to verify deployment and/or perform regression testing. I've got most of this working using groovy scripts, but it would certainly improve things if wrapped in a plugin.

The latest release of the Jenkins plugin that fixed a bug with the url parameter encoding also fixed the authentication issues.

Thanks for the pointers, Dean!

We need to add that.. but to back-up ProGet, you just need to Back-up the Database and the Packages directory (the path is listed on each feed, and is in the All Settings under Admin). Then restore the database, and the files on a new server.