It would be good to clarify the "Symbol and Source Server" document you linked to explain that you don't actually just want to push the symbols package; you want to push a package that contains everything. The way the document currently reads, which is why I got hung up, is that it talks about the two different packages - non-symbols vs. symbols - and then later says to only push the symbol package which is wrong. Symbol packages built with -Symbols don't include content files. I recognize the race condition issue, but the description that symbols packages only differ by adding symbols and source is incorrect. The typical symbol package only has symbols and source.

I'd be interested in this feature as well. We want to use the NPM registry but prevent developers from pulling newer versions that haven't been tested with our software. We'd also like to block on major, minor and patch revisions. Thanks

ASP.NET 500 errors should appear in the Windows Event Log, check there for full details, though this sounds like an error with the nuget.exe client rather than ProGet.

Currently, the Git provider only monitors a specific branch + path combination in source control. You can however, set up multiple SCM-triggered builds, each pointing at the desired "release/*" branch.

I see, in that case, your network/server is not properly configured. This is not trivial to troubleshoot, and this is happening before the request hits our software. The most likely culprit is an invalid/missing SPN, and a domain administrator must add that. Here are some additional resources to follow: https://support.microsoft.com/en-us/kb/969060 http://www.sidesofmarch.com/index.php/archive/2011/11/04/troubleshooting-windows-authentication-in-iis/ http://serverfault.com/questions/341978/troubleshooting-windows-authentication-problems-no-challenge-in-iis-7-5 Search terms, "diagnosing windows authentication iis"

Although the VS2015 release is around the corner, we don't believe the v3 API will be ready/stable for public consumption yet. There are no currently no API docs, and the codebase is still moving too much to try to guess what will it will be. We reverse engineered what we could with NuGet3RC2, and it seems to use a blend of v2/v3 API calls. Once the API is ready, we will likely use it to implement the "nuget.org cache" feature that's on our roadmap. That said, the NuGet team will need to (and plans to) support the v2 API in both their client and server components for many years to come, so we're in no rush. The v3 API will primarily offer performance improvements for reaching NuGet.org, but ProGet users aren't really impacted by performance problems anyway, due to local server caching.

You can set up a retention policy that will handle this feed cleanup.

Thanks for letting us know; we're currently waiting on the NuGet v3 API to be released before spec'ing this out further. It's scheduled to ship with VS 2015 later this month, so we'll have a better idea after that. It used to work, and it still kind of does depending on the time of day... but NuGet.org's performance has degraded significantly over the years. Now it's very hit-or-miss, and the longer the package filter list, the higher the chance your connector will time out.

Sorry about that - we accidentally broke SDK compatibility and will have to release a newer version of BuildMaster (v4.7.5) that will have a shim for that method. As a workaround for v4.7.4, you can call: StoredProcs.Applications_GetApplicationsVisibleToUser("Admin", "", 1) to get apps visible to the Admin user of the built-in directory provider (substitute a domain user name and use directory ID 2 if you're using LDAP). This of course assumes the default setup where "Admin" has privileges to view all applications.

This error means that ASP.NET is not installed/enabled; it's a setting that's available in the server manager console, role/feature settings. Here is a guide from Microsoft on how to enable this: http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-using-aspnet-35-and-aspnet-45

Thanks Dean - that was super helpful :) I resolved this issue by only promoting the symbols package if one existed. Many thanks!

npm changes its access URLs a lot, and from looking through its checkin history it usually seems to be accidental. ProGet currently supports two URLs for adduser: /-/user/org.couchdb.user or /npm/[FEED]/-/user/org.couchdb.user[...] I've never seen any version of npm use a ~ instead of a - before... What version did you upgrade from?

Thanks for the bug report. We've just published v4.3 of the NUnit extension which should resolve this issue.

You might be able to get away with this with some git trickery, i.e. you can have a script at the beginning of the deployment plan that lists the remote branches and gets the latest commit time for each one, and writes the branch name out to a file (or something like that). Then you can use the "Set Variable Value from File" action to save that value into a BuildMaster variable, and reference that in the "Get Latest" action. Hope this helps :)

Tod. Looks like whatever you discovered was right. Added an exclusion of example.org, and I can now query and cache through a ProGet feed

As of BuildMaster 4.9, many of the restrictions in the express edition have been removed. #####Features Available Only in Enterprise Edition (4.9 and later): Enterprise Support Active Directory / LDAP Integration #####Limitations of Free Edition (4.9 and later): 5 Users 10 Applications 5 Servers The following information is outdated, but remains for users of older versions. #####Features Available Only in Enterprise Edition (4.8 and earlier): Enterprise Support Active Directory / LDAP Integration Automated Promotion Requirements Change Controls Configuration File Templates Database Change Script Deployer Deployable Dependencies Group-based Approvals Multiple Active Builds Scoped Privileges Server Groups/Pools #####Limitations of Free Edition (4.8 and earlier): 5 Users 10 Applications 1 Automatic Build / application 1 Configuration Files / deployable 1 Database Connection / environment & application 3 Deployables / application 1 Workflow / application 3 Environments 1 Imported Deployable / application 2 Issue Trackers 5 Servers 3 Source Control Providers

I tried that. Actually, the stop/start link started showing after I restarted the app pool and website. Please, keep me in touch for a solution. Thanks

It goes back to Day 1 of your install; you can query the table directly (it's [EventOccurences]) if you need to do some complex searching.

There is a bug in 3.7.x that will be fixed in 3.7.4 On the proxy configuration page, can you enter a dummy value into "Exclude URLs" section, e.g. "example.org"?

No problem! Now for a barrage of questions... Where is the 503 response coming from, ProGet or the proxy server? Is there an error message in addition to the status code? What do you mean by "use the ProGet feed", does that mean browsing the ProGet web application (i.e. feed overview page), or accessing packages via nuget.exe/Visual Studio? And does it work as expected if you access ProGet over HTTPS?