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

Hi @gravufo, The Inedo Hub lets you select which version you would like to install from a dropdown. You can also customize the feed that you would like to look for those packages. If that does not cover what you are looking for, technically you could generate offline installers for each version you would like to keep. Thanks, Rich

@atripp said in Proget 5.3 Docker Image: proget.inedo.com/productimages/inedo/proget:<version> Pulling that image is very slow! Can't you mirror the image to docker hub please?

Thanks for the fast resolution

Thanks for the report , very simple code typo and now it'll be fixed in BM-3611 in the next maintence release

@atripp . Thank you very much. Especially for pointing to right docs.

Hi @antony-booth_1029 , Looks like we had an issue in how the javascript resource is loading for this modal. I have fixed this and it will be released in the next version of BuildMaster 6.2.14 which is due out at the end of this week. Thanks, Rich

Hello, great question. .indeox deployment is no longer supported, so I updated the documentation as follows Direct Deployment {#zip-file} An extension can be directly deployed to an Inedo product's extension root as a simple universal package. To do for an extension named MyExample, first create a manifest file called upack.json with the following contents: { "name": "MyExample", "version": "1.0.1" } Then, create a zip file called MyExample.zip with the compiled output in a package folder, and the upack.json at the root, like this: /package/ /MyExample.dll /SomeLibrary.dll /upack.json Rename the the zip file to MyExample.upack, and copy the .upack file into the Product extensions directory. By default, this will usually be in C:\ProgramData\«product-name»\Extensions, but you can verify the exact location by going to the Admin->All Settings page and looking for the ExtensionsPath value. Finally, restart the product services (and application pool if hosting in IIS).

Hi @luminiscence_6236 , I'm glad to hear you figured out the issue. I'm going to add an internal ticket to add better error handling around docker connectors. Thanks, Rich