That sounds great! I'll mail you some testcases for reproducing the issues we ran into shortly.

I have found the solution ... Set the Property "UseIntegratedWebServer" to False in the Advanced Config when use IIS. The solves the problem

Thanks Alana, issue has been fixed now.

Thanks Philipp i will findout the script to delete the files.

At this time, the NuGet team has no plans to make the v3 API publicly consumable, and will support the v2 API indefinitely as the public API; as such, we have no intention to reverse engineer and attempt to implement a private API. Note this it is entirely a "behind the scenes" transport mechanism (JSON vs XML) and makes no difference at all from a usage perspective.

Hi, please refer to https://docs.nuget.org/create/creating-and-publishing-a-package and https://docs.nuget.org/consume/command-line-reference; just make sure to specify the ProGet URL for the --source option

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?