We don't have a built-in mechanism to do that just yet

Whoops, updated! It's http://inedo.com/proget/roadmap

You really shouldn't use API keys with ProGet, actually. From the docs: An API Key is used by NuGet client tools (such as nuget.exe and NuGet Package Explorer) as an authentication mechanism for publishing packages. It makes a lot of sense for the NuGet Gallery, as it's a community-run site where anyone can publish packages they own. In enterprise environments, the notion of individual package ownership doesn't quite translate, nor does the usage of API Keys. With ProGet, a principal (user or group) either has privileges to publish a package to a feed, or does not. This allows ProGet administrators to more easily control access and usage through LDAP and Groups instead of through community mechanisms like API Keys. So, if they can authenticate to the feed (using basic auth or windows integrated auth... or even an api key in the form of user:pass), and they are authorized, then the can push a package.

If the installer is signed by Inedo, then you can be assured it's a false positive. We have no control over how A/V companies detect "viruses", but if you could please report this as a false positive, then they will be less likely to falsely detect our installers.

Thanks, Dan. It looks like this resolves the issue I was seeing as well! Now I just have to figure out why my ProGet server won't do a full index of npm without having the connection forcibly closed, but at least I'm back in business.

It's not that "tags appear to become meaningless once a newer version of a package is present", it's just that tags are part of an individual package's metadata (see the NuSpec Reference) just like name, description, authors, etc. The VS Client, nuget.org, and every other package manager UI we've worked with will only do metadata search on the most current version of a package by default; otherwise, outdated and irrelevant packages would come up in results. As you can see, it's possible to use an API to search for these things... but tags are simply not intended to solve the problem I think you're trying to solve.

Is this feature now available? Where could I find documentation to this?

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.