Hello Dan, Exactly what I needed. Thank you for the prompt reply! Mikhail R.

Thanks @mcascone , I also added this to our "Promotion / Repackaging Visibility & Permissions Rethinking" task - sounds like something we can consider :)

Thanks, yeah, that seems to work. I changed my pipeline code to not send any title metadata to ProGet, which returned that field in the UI to its original behavior. I also found that rebuilding an existing package, and sent to ProGet with the updated pipeline, has the same effect.

@mcascone yep, that's a good way of putting it!

Hi @patrick-groess_2616 , The /symbols/<feed-name> URL is only for Visual Studio's Symbol Location setting, and is used to download symbols. Do not try to use it with nuget.exe, it will give that error. You need to use /nuget/<feed-name> to push symbol or nuget.exe packages. Thanks, Alana

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 .

Hello; I'm not able to reproduce this on the latest ProGet, and I'm thinking the problem may have been the package file was on disk from the previous version. Here's what I did: Create a new Feed with a connector to NuGet NuGet Download package using the URL /nuget/nuuget-public/package/ProxyKit/2.3.3+build.0 File on disk is ProxyKit.2.3.3.nupkg Cheers, Alana

Thanks for the detailed writeup! We've just published v1.0.1 of pgscan that should fix the issues you've described. v1.0.1 will now actually write errors and other info to the console like it's supposed to. There is also now a --api-key argument to allow it to authenticate with ProGet. Downloads are here: https://github.com/Inedo/pgscan/releases

Hi @scroak_6473, That's great to hear that the impersonation has fixed the issue. We have fixed this issue to not require impersonation in ProGet 5.3.2. I will let you know if anything changes! Thanks, Rich

Hi, I'm sorry I don't seem to have got a notification email when you replied, so I only just saw this. I just tried 5.2.29 and it works perfectly. Many thanks!

Just for reference, I was able to get the correct digest of a tag and delete it with this PowerShell script... $image = "some_image" $some_image_tag = "some_tag" get digest $curlReturn = curl -I HEAD https://<proget_repo>/v2/<container>/library/$image/manifests/$some_image_tag foreach ($line in $curlReturn) { if ($line -match "Docker-Content-Digest: (.+)") { $digest = $Matches[1] Write-Host "$image digest is $digest" } } delete tag digest $URI = "https://<proget_repo>/v2/<container>/library/$image/manifests/$digest" Write-Host "Deleting tag $some_image_tag from image $image" Invoke-WebRequest -Uri $URI -Method Delete -Headers @{"X-ApiKey"="<proget_api_key>"; }

Hi, Thanks for letting us know. Looks like the error message is wrong - actually the problem is caused by build metadata being present in a version number that is not a semver2 version. We've filed this as PG-1655 to make parsing these versions more permissive - it will be fixed in the next ProGet release (5.2.23), currently scheduled for Jan-17.

Hello @luminiscence_6236, It looks like ProGet is misinterpreting the auth token request helm sends during the second command as being anonymous. I've filed PG-1651 to address this.

Hello; this will probably be the fastest route to fix things -- https://docs.inedo.com/docs/desktophub/troubleshooting

@atripp Thanks for the clarification, you have me pointed to the tooling and steps I will need to perform the bulk import. I will have to try, but I think I have enough information to script this task.

You should have access now! Let me know if not :)

Great news, Alana! Thanks.

Thanks a lot, I confirm it's working now with v5.2.9

Hello, Sorry for the confusion. For your solution you would need two separate feeds. One for normal package, one for symbols. Thanks, Jason

Hi Chris, You'll need to run the NuGetPackagesV2_SetListed method instead. In order to this, you'll need to mark it as non-internal; this can be done with a simple database query... UPDATE [__StoredProcInfo] SET [Internal_Indicator] = 'N' WHERE [StoredProc_Name] = 'NuGetPackagesV2_SetListed' This will be also be updated in 5.2.10 as PG-1549.