@wsah_6160 @pluskal_4199 assuming this is related to 5.3, then there should be a fix coming soon!

FWIW, i'm using the Versions API endpoint to get the list of versions, and you could build your own parsing from there. I'm sure this is mostly wrong, but this is what I'm doing, in Jenkins: // get latest version of package on proget // https://docs.inedo.com/docs/upack/feed-api/endpoints#list-versions // compare to build's versionfile def response = httpRequest ignoreSslErrors: true, url: "${env.progetUrl}/${env.progetFeedType}/${env.feedName}/versions?group=${env.groupName}&name=${env.serviceName}", wrapAsMultipart: false def content = readJSON text: response.getContent() // Versions are always returned as an array, even if count = 1 // So just always get the last element in the array. env.latestVersion = content.version[-1] echo "Latest published version is ${env.latestVersion}, date: ${content.published[-1]}" echo "Jenkins is building version: ${env.tag}" // compareResult returns: // -1 if v1 < v2 // 0 if v1 == v2 // 1 if v1 > v2 compareResult = compareVersions v1: env.latestVersion, v2: env.tag

Re: WARN: Error initializing server .NET 4.5 (ID: 11): System.Net.Sockets.SocketException A SocketException is thrown by the Socket and Dns classes when an error occurs with the network. Most of the time these are connectivity issues due to different IP protocols (IPV4/IPV6) between the two server/computers trying to communicate or extra authentication rules setup on one of the computers for in/out connectivity. Ways to troubleshoot the issue are, check you have proper internet connection is there on your machine or not, and you are able to ping the remote server or not. Possible causes for the error: You are using the wrong IP address. You are using the wrong port. Firewall blocking the connection.

Hi @Jonathan-Engstrom, Have you reviewed the Backing up Otter documentation? We outline how to backup and restore a ProGet instance in there. If you are missing configurations, it shoulds like you may not have copied all of the files from your git repository or the configurations were not stored in the Git raft. Do you still have access to your old server? You could also navigate to Administration -> Rafts and download your Git raft as a zip file as well. Thanks, Rich

Hi @rhessinger I will be out of office for the next weeks. I ll make the test when I come back Best regards PhilippeC.

Hi @gdivis I can confirm that TimeZone can now be specified as an environment variable in ProGet 5.3.7 Thanks for including this! Simon

I tested the following: changing the nuget connector to utilize v2. The effect is the same where I cannot pull from nuget.org. This definitely worked prior to v5.3 Right now i have proget running a v3 api for the feed with a v2 connector and it is working fine so far. I believe its a bug when the feed is running v2.

There's no limit set by ProGet to the size of a feed, and we have customers with terrabytes of packages, so it should be okay.

We finally got to the bottom of this. Environment variable was right, but there was an old container hanging around in the background confusing the docker network about what should match our proget_db.

Hi @scroak_6473, Glad to hear it! Thanks, Rich

Hi Philipp; Glad you were able to find the feature of Repackaging, it's quite helpful! Now, when the WPF Application is going to be tested, we'd like to generate a whole tree of all those dependencies labeled as "-prerelease". And after testing we'd like to move the whole tree into the production state where all packages do not have any prelease tag at all. This sounds good to me! I think this process makes a lot of sense to do. I'm not sure if you're asking about the ability to tell ProGet "repackage the WPFApp package and all it's dependencies", using one API call or something? In this case it's not possible. The reason is, it's not feasible for ProGet to handle the dependency resolution. Actually it's quite complicated (especially with version ranges possible), and NuGet's algorithm is among the most complex in the industry. Because of this, it's not really possible to do dependency resolution from ProGet, since you'd need to specifying additional context including what framework version you're targeting and what version of Visual Studio you're using, etc. But anyways, the idea you have to promote all packages in one stage sounds nice to me!

thanks a lot for the support, upgrade did work out great in the end, just had to update the IIS bindings and certificates back to the customized ones

Hi @gravufo, Awesome! Just reply back here if it does start up again. Thanks, Rich

What you're describing is a "drop folder", which ProGet has for some feed types -- they're not supported for asset directories, however. Do note that there is an Import Directory Endpoint in the Asset Directory API where you can publish a ZIP file that gets automatically extracted.

thanks for the help :) i think i will write a script.

Hi, I've increased all the possible timeouts, but the issue remains. As another PoC, I've spun up a temporary pod with ubuntu 18.04 on our AKS cluster. kubectl run my-shell --rm -i --tty --image ubuntu:18.04 -- bash Installed powershell 7 in the pod and then registered the repository with register-psrepository -name psmodule-test-sourcelocation http://<instance>/nuget/psmodule-test This works and installs the module On a sidenote, we also have octopusdeploy running that pulls modules from proget. This also works. I'll ask our networking team to temporarily allow http traffic to proget. To test if this issue is caused by ssl or the inverse proxy as a whole (traefik). If it's the latter, then I guess we eliminated all possible steps on this :)

Hello, Please see the guide over here - https://docs.inedo.com/docs/proget/feeds/nuget/symbol-and-source-server If you wish to use a separate symbols package (snupkg), then you will need to create a separate feed, and push the symbols package to that feed.

Hi @antony-booth_1029 , Yes, this also corrects the size of the modal when it pops up as well as a few pieces of the form that is not working correctly also. The bug was basically the javascript resource for that modal moved and the page was still referencing the old location. Thanks, Rich

Hi @antony-booth_1029 , I have fixed this issue and it will be released in BuildMaster 6.2.15 which is due out on July 17. I'll post back here if anything changes. Thanks, Rich