Hi @pfeigl, Thanks for letting us know. It looks like this is related to how HEAD requests were handled. I went and added that header to head requests also. This will be tracked in PG-2300 and will be released in ProGet 2022.25. 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!