I see, that's perhaps the most common usecase for ProGet, so it should just work. I suggest to attach Fiddler, or Wireshark, then compare the results between one computer and the next. Then you can see exactly what the results are. Something could be filtering it in between, redirecting to the wrong server with a hosts file, etc.

You recommenced ADInsight previously. It is an obsolete tool that is no longer maintained. It does not work in Windows 2008 R2 nor on machines with VMWare tools installed.

Believe me, we really wish it was feasible to provide "Integrated Windows Authentication" (i.e. 401/NTLM challenges) for some feeds, and "Anonymous" for others. The problem is that this is implemented at the HTTP.SYS stack level (a kernel-level service), which far below IIS. NTLM/Kerberos authentication is not something we can feasibly implement ourselves... even if we did, the TGS Exchange cannot really run in a protected environment (like an app pool user). This has been a known issue by Microsoft for at least 10 years, and they are planning to introduce some new libraries/options with Server 2016. There are rumors they will drop it altogether in favor of federated authentication (i.e. Azure style). But, it's not huge on their priority list I think.

Nice. It would be even better if you could see this log info next to "Last updated" while browsing a package.

The issue turned out to be more of a Nuget issue, I believe. According to Nuget's docs, I should be able to mirror my package by specifying the push package URL in the following format: (proget server)/api/v2/package/. However, this just grabs the first feed under /package. Instead I needed to specify the feed name: (proget server)/api/v2/package/myfeed

It's hard to say why there's a discrepancy, but you can just re-index the entire connector. Just run the "FullNpmConnectorIndex " scheduled task, accessible from the admin portal. This will take several minutes. There will be a LOT of warnings about "missing versions property". You can ignore thesethey are effectively invalid npm packages that they return anyway with the index request.

Visual Studio is filtering out your package because your project is targeting a different framework than your package is configured for. For example, you may have a net45 package and are trying to make a net35 project

I assume you can see the package when you browse the feed in ProGet? If so, then Visual Studio is filtering out your package because it's targeting a different framework than your package is configured for. For example, you may have a net45 package and are trying to make a net35 project.

Hi, This is an old thread but i have the same question. We're on 5.3.17 and have used up all of the space on C:\. We have 1TB on D:\, so I just want to move the PackagesRootPath to there. Does the above pattern still apply? thanks max

Just a quick note to add to this, there is a setting on the Admin->Advanced Settings page called AllowDropPathImportOverwrite that will allow drop path packages to overwrite feed packages when set to true.

Yes, there is, but I'm afraid we don't have a detailed set of instrucitons on how to do that. Effectively though, you need to install the certificate to the host name you wish to use, and then change the url to https. However, we strongly recommend using IIS hosting if you want to do this, as there are plenty of guides available on how to do this, and administrators will be much more familiar with how to manage certificates.

There are some disk usage reports on the Manage Feed Page, but they do not break it down overtime and by month. We simply do not store disk usage statistics -- only the current space utilization. There are likely some third-party utilities that will tell you disk usage peaks, usage over time, etc; you can point those to the disk path that ProGet uses for internal storage.

I've got it working now, but only with the port. I'd rather not have to do that, but it will work for now. I'd really like to know why I can't use a reverse proxy in front of ProGet to avoid needing to specify port numbers.

not currently, but it's definitely on our roadmap to do a caching in a similar manner

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