Maybe you want to write an Extension for ProGet that is invoked whenever a apackage is pushed to a certain feed. Once triggered, you cando whatever you need to do in your extension.

Hi Matt, I would suggest to attach fiddler, and see what's going on. That XML you pasted is what a NuGet endpoint looks like; from there you can append /Packages to the URL, and see more of the exposed API.

ProGet is currently on-prem only, though you could install an instance in the cloud quite easily (a lot of people do that). We will likely have a SaaS/hosted version in middle of next year.

The Active Directory user directory has since been open-sourced here: https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/InedoExtension/UserDirectories/ADUserDirectory.cs

Based on the message, it would appear the registry is not pointing to ProGet, but is instead pointing to npmjs.org. I would do a wireshark or fiddler trace to see where it's actually going, and note what's being passed through.

I get the same result with versioin 4.5.1. I try to change the connection string during the install but it still uses the default connection string and not the one I entered. I also tried to set it using the silent option. Then the installer fails without any message at all, not even to the specified log file.

Unless something has changed, you cannot use Integrated Authentication with npm because the client doesn't support it: http://inedo.com/support/questions/2647 However, if you enable LDAP authentication in ProGet and then disable Integrated Authentication, you'll be able to use your Windows credentials. If it's the backslash that isn't supported, try the Active Directory provider, which supports the user@domain syntax.

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.