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

@atripp this is great. Thanks. -Sri

Hi @scroak_6473 good to know! So, I've added the WORKDIR /usr/local/proget/ line right above our CMD line, and it should go in the next release.

Hello; Tags in Docker registries are really just a human-readable pointer to a digest (hash) of an container image. It's really just a name+digest, and there's no additional metadata provided by the Docker API. This is why we encourage Semantic Versioning for Containers, and have a feature built-in that helps with this. You can then reliably parse those tags like semnatic version numbers, and use them as needed. The Packages vs Containers documentation also talks about some of the quirks, if you're not familiar with them already.

Hi @shijiyong_6709, I just wanted to confirm that you are using docker login -u admin https://proget.company.com and not docker login -u admin. Is that correct? The first thing we need to figure out is if the problem exists in your ProGet configuration or in your nginx configuration. Can you start with temporarily allowing anonymous access to your Docker registry in ProGet, does Docker pull work then? Thanks, Rich

I don't have a detailed timeline with Otter 3.0, the scope appears to continue to creep (but, perhaps in a good way ). But it's still looking on track for early next year. Probably the best thing to do is to get in touch with our sales engineering team, so we can learn a bit more about what problems you're trying to solve, and can give some more details about how Otter 3.0 will help; they can at least show you what's upcoming, so you can better decide if it's a good fit.

Unfortunately, when symbol serving doesn't work, it can be a pain to diagnose... Can you "start from scratch", documenting your steps along the way, so that I can try to reproduce exactly what you're doing? Start by making a very simple, hello world sort of library (maybe one class, with some basic code you can easily step/through and debug). After that, then create some brand new feed (it sounds like you want two feeds? a symbols and a package feed?), then configure the new feed in Visual Studio. Then follow the other steps, like seeing if you can find the symbols in Visual Studios, etc. If you can share the exact steps you did, and the package you upload, then I can reproduce the error you're seeing by following steps using the package.

Hello; please restart the ProGet service. This will cancel all executions upon restart.

Sorry, wrong software - please see our friends at otter.ai for transcription. We do server automation. Cheers

@philippe-camelio_3885 FYI, we will add a checkbox for auto-purging soon, BM-3655

Hi @sbolisetty_3792 , just to let you know, this will be fixed in the next maintence release of BuildMaster (BM-3654). Basically, if a Server has a Single environment, then that environment will be used for credential resolution. HOWEVER, note that this won't work for your dev-cap server because it's in two environments. So in that case, you couldn't use an environment-specific credential.

Hi @arozanski_1087, That's great! I'm sorry it took this long to get this working. Thanks for working with me to figure this out! I'm going to make a change to the documentation right now to include the requirement of naming the extension file. I will also get a full release of this extension out today so it will lock in that version with the ProGet release tomorrow. Thanks, Rich

Thank for your suggestion. This command work for me dotnet nuget push notepad2.4.2.25.3.nupkg -k apikey -s https://proget-sample.com/nuget/chocolatey/