It's fairly rare to have 2 config files with the same name assigned to the same deployable, and when they are under 2 different deployables, an action within an action group in the context of a deployable will only show the single config file in the dropdown.

Thanks. Removing \SQLEXPRESS fixed it. -Michael

Upgraded to 3.7.4 and the problem is fixed. Thanks.

Thanks Dean, I modded the regex inline to get around the validation issue. Thanks for getting back to us on this.

Yes, most definitely. See KB#1072 - ProGet vs. NuGet.Server

It's not possible to add a new feed type via the SDK, but it's for sure on our roadmap.

We'll fix this in ProGet 3.7.4. For now, you can mark the feed as inactive to disable it. If you need to delete it, I can send you a patch to fix your installation.

Maven connectors need to be indexed before they can be used from ProGet. If you go to the Admin->Scheduled Tasks page, you should see an entry for a MavenConnectorIndexing job, and you should be able to see a log of the last several attempts. Did it appear to complete successfully? Also, you may want to try actually performing a search for the Maven artifacts. When browsing, we only display local artifacts, but connectors are displayed when you search as well.

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?