Last time it happened after 2 days (or maybe less, but that's when I noticed), but now it has been running for 4 days and it still works. We have been using the NuGet feed a few times during those 4 days. I will keep monitoring it and report back if I find anything!

ProGet 4.0.11 is now available, which includes support for scoped packages. You can get it from the downloads page: http://inedo.com/proget/download

Hi Alana, Any chance of sending that C# code to me as well? We are also facing issues getting multi-domain AD working. TIA

Only per feed, and that requires the Enterprise edition. The free edition only allows system-level privileges.

There's nothing special that ProGet is doing, it's effectively just inserting a SRCSRV stream into the pdb, exactly as pdbstr would. I'd also check out #3061, and specifically http://techblog.dorogin.com/2012/09/troubleshooting-debug-symbols-indexing.html

Thanks, it works (after we updated to the latest version).

ProGet on IIS is only supported as a root level web site of IIS - it cannot be a virtual directory of another application. If this is not an option, you'll have to go with the built-in web server option.

Currently, we only support the synchronization / replication of specific feeds using the MyGet sync feature. We may offer a ProGet <-> ProGet feed sync feature in the future, but there's not a lot of demand for it.

The "Proxy Configuration" page does not (currently) send an agent string; apparently, maven.org will return a 403 errors without an agent string, so you will get an error if you attempt to visit the maven central index (https://repo1.maven.org/maven2) from that page. However, the FullMavenConnectorIndex task (which is schedulable / runnable under Admin > Tasks) does send an agent string, and maven.org does not block that request. If you are getting a 403 during that task run, it's going to be coming from your intenral proxy server, not maven.org.

Thanks for the feedback. The HttpModule was not the cause. I just had to configure the NuGet.config credentials correctly in %ProgramData%\NuGet\Config\NuGet.Config, which is machine wide rather than user specific. I will distribute this configuration to all developer machines using an Active Directory Group Policy.

If you just either use the NuGetFeed constructor that does not take credentials, or set the credentials parameter to null, then it will attempt to use Windows Authentication for the current user.

As long as your support renewal is current and either you are upgrading the instance directly, or you have purchased enough server licenses to cover all running instances; it will just work. If you attempt to activate a key on a new machine that would cause the number of running and activated servers to be greater than the number of purchased licenses, there may be an issue with the activation and you wouldn't be able to use the software. For more advanced or specific scenarios, you might be better off contacting us directly.

The upgrade is a coincidence, and the problem could have been triggered by something as simple as restarting the application pool; this is handled entirely by IIS (more specifically, Microsoft Negotiate). Negotiate authentication uses Kerberos (see Kerberos Explained), and this is difficult to debug. You can search for things like “windows negotiate authentication fails” to find all sorts of tips, but this article has been a good resource. In my experience, the most common reasons this doesn’t work: accessing by a different url (buildmastersv vs buildmastersv.mydomain.local) having a time difference between server and domain controller not having certain patches/windows updates NTLM is a different type of authentication, which may not be desirable.

This answer doesn't answer the question. Is there anything else to check or try?

Ah, I see. We have been able to reproduce this - it looks like a regression in handling the feed-specific npm adduser URL. We've also always handled the /siteroot/-/... one as well because npm used to always use that regardless of the repository URL. I think that changed some time around npm 2.7 when we added the second handler. Regardless, we've already fixed this internally (again), and will be releasing the fix as part of ProGet 3.8.1 likely some time tomorrow. Thanks for the help!

The SRCSRV stream for downloaded PDBs was always empty. Once I added that stream ProGet correctly updated it to point at itself. I never saw errors on the /administration page of ProGet. Is there somewhere else to look? I'd like to be able to skip the local indexing step if possible.

Ah, ok, that would definitely be an issue. I've added another change [PG-449] to add a new property called BaseUrl. It should be out in the next maint release.

Thanks for the bug report! We've reproduced this and have fixed the bug in one of our pgSQL functions that was causing this. We'll have the fix included in the next beta (4.0.2) which will likely be released some time today. FYI- it's the same bug preventing changing the password on that page and adding a new user; we have verified that both are now working.

Would love to see a VSIX feed (didn't see a way to vote for this feature).

Ah I missed the snapshot creation option, because I only tested an existing ProGet 3.7.x maven feed I had. The checkbox is handy when creating new feeds since it'll save the step of whipping up another feed. Since nothing appears to prevent you from creating your own snapshot repository without the checkbox, and the snapshot feed appears to be fully configurable and separate from the other repository (which one would generally setup as a RELEASE repository) so - yeah - that feature seems good to me. Thanks a ton for adding the storage location override to the next release - that's really going to be useful. Of course, now I'm getting excited... so I have to beg for feed retention rules being made available for snapshot repositories as a free version feature -- like Nexus, Archiva, etc. If that happens, my journey to the dark side will be complete. :-) I can understand the wisdom in making that a pay-for feature for most all other repository types, but at least for maven snapshots, the general industry standard is to provide some mechanism to auto-purge snapshots (keeping only the last 3 - or whatever the user specifies, etc.). I can also say that these specific improvements being made will help making a stronger case to switch binary repo managers, as well as going pro to pick up the other enterprise features. So thank you for the help and new features!