Hi @m-karing_2439 , The link on the "Dependencies" is provided for convenience; it's simply wrapping a <a href=... around items in the .nuspec file's Dependencies element. Without performing expensive lookups, there is no way to know if those packages are in the current feed, or if they're even valid packages or versions at all. Keep in mind that, in many cases, dependencies won't even reference a single package (e.g. MyPackage-4.8.7) - but a whole range of versions (e.g. MyPackage-4.*). This is why it's impossible for ProGet (or any tool) to "resolve" the dependencies - it requires knowing all packages in project (plus the project's environmental configuration) to know which ranges to pick. Note that, if those links yield a 404 then clients will also not be able to download them from thet feed. Thanks, Steve

Hi @m-karing_2439, It looks like this is a network-related issue: "Cannot determine the frame size or a corrupted frame was received." There are no changes in ProGet 2025 that would cause something like this, but it's possible that a firewall or something else is interfering with the communication. The executable name changed from ProGet.Service.exe to proget.exe, and we've seen some "anti-virus" tools require a new execption be made. No idea why it would work for PyPi, however. Hope that at least points in the right direction. Thanks, Steve

Good news @m-karing_2439 , This works in ProGet 2024! More specifically, when rewriting/refactoring the PyPi feed, we added support for this "unconventional" repository - specifically, one that doesn't follow the /simple convention or use any of the JSON/warehouse api. Cheers, Alana

Unfortunately this is just an invalid package... someone really needs to tell the developers at Microsoft that the developers at Microsoft really want packages to be in SemVer2 format, per the Microsoft documentation https://docs.microsoft.com/en-us/nuget/concepts/package-versioning Microsoft's documentation seems to no longer describe what Microsoft's once documented "legacy versioning" used to be, but we captured it in our documentation before Microsoft removed it. Bottom line, the "." is an invalid character in a non-SemVer2 (i.e. four-part version number) pre-release tag. Hence, why it's getting a 400 error. It used to do that on NuGet.org, too. I guess it doesn't now. We probably won't change this, since it kind of works already., and since it's only one package. But if you email the Microsoft team responsible for that package, they probably will just change their versioning going forward. IT'd be nice if Microsoft documented how their non-SemVer2 packages are supposed to work.