Under the package retention options, it would be handy to have rules for how long to retain unlisted packages. We run our own retention scripts using nuget.exe to do the delist, but there's no way of having the delisted scripts be cleaned up outside of the same retention rules that apply to all packages.

I would love to see Azure DevOps Yaml Examples

When I try to connect using github authentication, MyGet requests:

Personal user data
Full access
This application will be able to read and write all user data. this includes the following:
Private email addresses
Private profile information
Followers.

This is obviously far too much privilege, and I refuse to authorize myget this level of access.

Supporting Kubernetes Helm chart repositories

When you need to unlist/delete/pin multiple packages the UI is very slow and unintuitive.

Either:

A. Make more options from the Unlist/Delete menu, like "all beta packages" "all packages before/after date" "all pacakges before/after version"

B. Add a checkbox to each version and have the options Unlist/Delete checked (preferred)

Thanks

I want some users to be able to publish packages, but only as pre-release versions. That way I can be in control of the "official" versions.

I've selected number of my projects (Not all Repo projects) to be built in the Build Service configurations.

The problem is a build is trigger if commit made to any file in the repo, MyGet should only trigger builds if changes are in the defined list of projects to build.

Since we need to manage the user accounts separately when people leave the organization, it would be nice if I could get an export of all the current users in the system so that I can compare it to what users are active in our AD, paging through hundreds of users and searching one at a time is cumbersome.

It would be nice if I could assign rights to Azure AD groups instead of individual users.

Also, disabling accounts if they no longer exist in Azure AD would be a big plus.

the ability to remove packages so that only the feed owner can see it. This would be so as to keep packages (and their stats) around but not available for download

I would like to block package download based on a vulnerability (or license) type.

It would be great for mobile development teams to have support for Maven + CocoaPods + npm (Android + iOS + ReactNative) in one place.

Following doc explains how to set up a private Pods repo: https://guides.cocoapods.org/making/private-cocoapods.html

I tried using nuget.exe delete command but it returns not found error

The licenses view with pie chart is great, but I'd like to be able to download the license report as a CSV file. I need to provide a report of licenses for due diligence purposes and giving a login to MyGet to view it directly is not a viable option.

myget currently displays the content of README.MD from my master branch (which is perfectly fine in most cases) but sometimes the release I'm working on includes changes to the README and I would like to be able to review these changes before merging my release branch into master and publishing my release.

I'm hoping that a more secure ADFS experience/workflow can be created. I would like to see a situation where an administrator can restrict token-based authentication for feed consumers and the consumers can use some sort of Nuget ADFS CredentialProvider to authenticate against the feed. (Perhaps with single-use, short-lived tokens generated by the provider?) That way when an AD account is disabled there is no need to secondarily disable a myget account.

https://www.visualstudio.com/en-us/docs/package/nuget/auth

There are some external tools I'd like to use during my build that are distributed by chocolate.org. Do\could you support build.bat using choco to install those tools on the build machine? I'm assuming the build machines are snapshot VMs that get reverted after each build? That would also be nice to know\have documented.

My build produces six different build logs that I would like to examine for each build. You could identify them by suffix. Mine are suffixed with diag, detailed, normal, error, summary, and warning. Or you could choose a suffix. Say anything ending in build.log. They get big so maybe you only need to retain them for a few days.