There is nothing in ProGet you can change at this time that would get around this. Maybe you could create another website that for example, redirects requests from http://repo.ingresso/nuget/ingresso-nuget to http://nuget.ingresso/ ? I'm not sure how well that would work though as it relies on the clients themselves following redirects. You also may have some luck with IIS URL Rewiting.

We will implement retention policy filtering by version. See the tracking issue here for updates: PG-1278 Hopefully it will be in the official v5.1 release (or soon-after maintenance release) but it may also be there earlier since we are also going to allow pre-release product versions to be downloaded from the Hub installer.

Yes, that's just fine!

The connector authentication is for basic auth, if you're using integrate authentication then it may not be required (assuming that it's configured properly on the Windwos/domain side)

Yes, we are in the investigation phase of adding this feed type. If it turns out it's as simple as sharing the functionality of the NuGet feed, it will be released earlier rather than later, but we do not have a scheduled date yet as to when it will be shipped.

These "URL scanners" all use the same, third-party reporting source, so they will all report the same false positives. We have no control over that obviously, and this only seems to affect certain URLS (not files or content at the url), and only for a couple days... which reaffirms that these URL scanners are fairly worthless, since a malicious file would just use a dynamic url. If you are concerned about the url scanner, then just use a different url to download the file --- https://s3.amazonaws.com/cdn.inedo.com/XXX instead of http:///cdn.inedo.com/XXX Even if Amazon's CDN servers were compromised , you can be rest assured that, if the installer you download is signed by Inedo, then it's the package we published. You can always manually install if you are you don't trust installers. WE would appreciate, however, if you report the false positive, as that's the only way these 3rd party reporting services will update their lists.

Yes, the privileges are scoped to a certain feed. You're right, As soon as i scope to "All Feeds", login works. That's great! I'm still abit confued about how to limit some people to only one feed. They should be able to Add, View, Download packages of one feed only (including uploading packages using the web ui). Other feeds should not be visible to them. How to achieve that without scoping my privilege to a certain feed. What I didis to create a new Role "HomePageViewer" Role with only the General_ViewHomePage Task. Then, I've created two assignments for my ProductDevelopers group: Principal:ProductDevelopers, Role:Package Consumer and Adder, Scope: MyFeed Principal:ProductDevelopers, Role:HomePageViewer, Scope: (System) Would that be a recommended way or did I think too complicated?

if you specify the /LogFile=[filename] argument, then the install log will be written there.

We made and tested several changes to the installer a while back, but it's not something we regularly test/verify. Please share what you find work! Thanks.

The installer has an issue creating the initial database due to a (recently) undocumented change on their end, but you can fairly easily work-around the issue until the installer is adjusted for this... see Question #3924.

Got it working. Thanks, that helps a lot!

We don't have that as a retention policy currently, but can consider adding it in the future!

You could use the API to delete one by one of course, but If you delete the packages from the store on disk, and then manually run the feed clean-up indexer (Admin > Tasks), then it will do the same.

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?