Gordon,

Have you made any changes to the web.config in the Proget website? Also, can you go through some of the IIS settings as well? Version of IIS, authentication modes that are enabled. Also, take a look at the providers for 'Windows Authentication' and what does that list look like?

I did a little digging and found a somewhat similar situation on a completely different product (SiteFinity). In that forum discussion there is talk about changes in the web.config causing the issue. Thus why I'm asking about what your proget installation web.config looks like.

https://www.sitefinity.com/developer-network/forums/bugs-issues-/error-throw-then-pool-web-app-restart

Please note, I do not work for ProGet, I'm a fellow customer offering assistance.

I'm not sure if you can use the V3 url in a ProGet connector. I believe I've tried and it wouldn't' work. I defer to ProGet employee's to confirm that.

However, that won't affect your developers using VS 2017. They can connect to ProGet with the url that you provided earlier and they will see the same results. I have about 80 developers across VS 2013, VS 2015 and VS 2017 all using the same ProGet url, and all are working fine with the nuget.org connector in ProGet.

Please note, I do not work for ProGet. I'm a fellow customer offering assistance.

As an alternative choice you can use Powershell for this. Add a 'Windows Powershell' step (be sure to install that Jenkins plugin first):

DIR -Recurse -File -Filter "*.nupkg" | @{
& nuget.exe push $_.FullName -Source https://urltoyourproget/nuget/feedname
}

You will also need to ensure you have the nuget.exe command line executable available to the Jenkins node running.

Please note, I do not work for ProGet, I'm a fellow customer offering assistance.

You are correct, the 'NuGet Uploaders' task is a custom one I made, it's been a while since I did that and did not immediately recall it as such.

That said, our use case is that the one administrating ProGet (myself and a few others) define what licenses are allowed in a separate feed. We have a set of developer architects that are responsible for reviewing which packages get put into the feed. Some of the packages they appropriately want to upload to the feed have an 'unknown' license. The dev arch then looks into the package and sees the url pointing to what reads as a particular license (likely a file in the project github repo). They would assign it correctly.

We would watch the new url license assignments and verify (trust but verify) ourselves outside of that process to allow them to move forward. Below is a workflow of what we have setup:

Arch upload -> import-nuget-feed -> assign license -> arch promote -> approved-nuget-feed

• Arch has upload access to the import-nuget-feed
• Arch only has promote access to approved-nuget-feed
• approved-nuget-feed has license restrictions on it
• Arch would assign license of the package while in the import-nuget-feed
• Devs use approved-nuget-feed for development

The archs would not need proget administrative rights, because they are not administrating the running and operations of Proget, just the content within it.

I hope that makes sense. I appreciate your time in this.

What permissions are required for a group/user to be able to 'Assign License' to a package that has an 'Unknown' license in the nuget/node package in a specific feed?

I am logged in as an Administrator and see the 'Assign License'. However when I give someone the 'NuGet Uploaders' task they don't see the 'Assign License' button. I also added the 'Manage Feed' permission to the 'NuGet Uploaders' task to see if that would work but it did not provide that button to the user.

Product: ProGet
Version: 4.8.2

Wonderful!

Worked just as you said it would. Thank you very much Alana.

I can understand what you are saying regarding 'system level' tasks. However, I'm not trying to scope a system level task.

In my original question you may note I'm trying to scope 'Download & View'. Which upon looking into the 'Cusomize Tasks' as you mention (thank you for pointing that out to me, very handy), the 'Download & View' has 'Download Feed' and 'View Feed' only. And both of those have the 'F' marker denoting that it can be scoped to a feed. Yet, my display shows 'n/a' still.

Am I doing something else wrong?

I will definitely look into the extension documentation. Thank you for mentioning it.

But, you're saying this won't work?

https://www.nuget.org/api/v2/Packages()?$filter=**IsPrerelease eq true**&$top=10

I imagine I'm misunderstanding something you said, or there maybe something else I'm not aware of when querying nuget.org.

Upgraded from 3.8.1 to 4.8.2.

Now in 'Tasks' I see 'Scope' set to 'n/a' on most of our assignments. We have the same groups granted permissions to multiple (but not all) feeds. How can I now see the details of these permissions?

Example of how it looks:

Task :: Scope :: Users & Groups
Download & View ::  n/a ::  AllDevelopers, AllDevelopers, Vendors, LicenseRequired, LicenseRequired

Example of how I'm expecting it to look:

Task :: Scope :: Users & Groups
Download & View ::  ApprovedNugets ::  AllDevelopers, Vendors, LicenseRequired
Download & View ::  LicensedNugets ::  LicenseRequired

This is so that I can confirm that the settings are correct. The way the UI is now, I have no way to know if the settings are correct and which ones to remove if need be. Note, the security is correctly applied (those that should have access do, those that should not have access are correctly denied), it's that I cannot see the settings as I did before.

Product: ProGet
Version: 4.8.2

Recently went from 3.8.1 to 4.8.2 and now have better connector functionality, thank you. However, we are seeing the pre-release packages show up in feeds with a nuget v2 connector. How can we filter those out? Specifically when we view a package with dependencies if the dependency has a prerelease package, that's the one we end up seeing and linking to in the web UI.

An example:
Serilog.Sinks.File v3.2.0 requires Serilog (>= 2.3.0)
Serilog's latest published version is 2.5.1-dev-00890 (which we don't want to see in ProGet).
Serilog's latest non pre-release/stable version is 2.5.0 (which IS the one we want to see in ProGet).

An alternative behavior would be that the pre-release ones show up but everything would default to using stable/non-pre-release packages unless specifically called out to include them by the user. Same as on nuget.org.

Product: ProGet
Version: 4.8.2

I'm still seeing that caching problem that you mentioned.
v3.8.1(build10) IIS hosted

1. Edit feed that has no connector
2. Add connector "http://localhost" (for testing, others can do the same as long as it errors on first try)
3. View the feed, see the delayed 'loading' and then the 'error with a connector' at top
4. Edit feed again. Remove that connector (just the red x)
5. View the feed, see the delayed 'loading' and then the 'error with a connector' at top
6. Edit feed again, change description (or something to trigger a save).
7. View the feed, see the delayed 'loading' and then the 'error with a connector' at top
8. Recycle app pool
9. View the feed. Problem gone.

I repeated the above process three times to make sure. I also waited about five minutes between step 4 and step 5 to see if that would do anything.