Hello; That search syntax is really only supported by NuGet v3 API, I think; so, ProGet simply forwards on the query to that API, and returns the results. But regardless, connector filters need to be applied after the remote feed returns results, because connector filter logic can be more complex that what is supported by the various feed APIs (you can allow Microsoft.* and Inedo.* for example). More advanced connector filter options are definitely something we've considered, and we'd love to do things like "version: 3.*" for example. But, it's a lot more complicated under the hood, and probably isn't even feasible given the nature of feeds. Alana

I had such problem with localized account with a lot of software :) Managing the [Otter / Buildmaster / Proget] service Account from the InedoHub would be nice. Philippe

Hey @atripp I know this is still a beta. Happy to help you Philippe

Thank you for the response and the incredibly fast fix! I will get my instance upgraded and test it out. Thanks again!

Thank you! Will do.

Hello; I'm not sure if we can help here, this sounds like something more appropriate for Azure DevOps community.

@andrew_5903 thanks, I'd like to update the docs! Did you end up writing a script to just call that for each Jar+Pom in your directory?

Hi @Crimrose, Thanks for posting a follow-up solution for this! I'll keep this in our notes incase this comes up again in the future! Thanks, Rich

ProGet does not support package-level permissions; you would need to create separate feeds, or create a custom package filter (in C#) that could have some sort of filtering logic per user.

Hi, i'm running into this now in Version 5.3.17 (Build 19). All of our packages are internal use only and i don't want to bother with setting up license rules. Can i disable the license checking?

Hi @Crimrose, this would probably be better to check on the Chocolatey forums / community site. But if you can find the answer, please share it :)

Hey @apxltd , Yeah having to deal with Microsoft on many different issues ourselves I totally get what you mean with this picture. I also totally understand your point and that makes sense! I'm glad the NuGet teams also push for the changes when they can. For us since everything is standardized and automated using the NuGet Restore task in our DevOps build pipelines yes it's really more convenient for us to point to our Proget Feed (thanks again for your product) and gather everything from there. We can for sure find workarounds also on our side but we had to try and contact your team as your company has been way more helpful to us than any support from Microsoft. Thanks a lot for yours and Rich`s precious time spent helping us through this issue.

hi Simon, The default connection pool size for .NET's SQL Server connection is 100, so that behavior wouldn't be unexpected if there were a lot of requests to ProGet (very common in a package restore) and the database driver wasn't responding fast enough for whatever reason (also very common... too many network requests coming in, too many network requests going out, slow database server, etc.). The .NET Runtime will eventually close those connections, and they will then be terminated by the TCP stack shortly after (minutes?). Alana

Hi @scroak_6473, We have fixed the issue with creating new AD User Directories and vulnerability sources in .NET 5. It is set to release in ProGet 5.3.19 which is due out December 18, 2020. Thanks, Rich

Hi Peter, Thanks for reposting this; this error is basically what you can expect from a "network stack" being overloaded; each request to a ProGet feed can potentially open another requests to each connector configured (maybe NuGet.org, maybe others), and if you are doing a lot of requests at once, you'll get a lot of network activity queuing up. SQL Server also running on the network, so those just get added to the queue, and eventually you run out of connection. Do you have a lot of containers running on the same computer that ProGet is running on? If so, that coudl also contribute to the network stack being overloaded. The best way to solve is with more hardware, or by removing connectors to nuget.org, etc. Also note that users can overload a server as well, and this is why load balancing will be very important if you want to keep reliability; See How to Prevent Server Overload in ProGet to learn more.

Yeah, that's a nightmare and a half and I can see why you did that. Currently I've tried repackaging the nuget but it brings about other errors, where it restores properly but later on in compile I get build errors. Right now I'm using the legacy version/older version of the nuget URL instead of the current v3 one until they get off of that package and I can remove it from my feed. It follows the format: https://url.domain/nuget/feedName/ instead of https://url.domain/nuget/feedName/v3/index.json .

Alex-Hempel said in Proget Jenkins Plugin: Not working on Slaves?: Caused by: java.io.NotSerializableException: com.inedo.proget.jenkins.DownloadPackageBuilder java.io.NotSerializableException can occur when you serialize an inner class instance because serializing such an inner class instance will result in serialization of its associated outer class instance as well. How to solve it? If the class is yours, make the class serializable by implementing the interface java.io.Serializable. All non primitive members implement Serializable (or are transient instead) If your class is an inner class it's either static or the outer class implements Serializable If the class is 3rd party, but you don't need it in the serialized form, mark the field as transient It is important to note that Serialization of inner classes (i.e., nested classes that are not static member classes), including local and anonymous classes, is strongly discouraged.

Okay, that isn't a good end-user experience. I switched to IIS hosted site and don't see this happening anymore now. Thanks for quick response. -Sri