Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

ProGet: Handling of deprecated NuGet packages



  • Hi there!

    It seems like ProGet currently doesn't handle NuGet's package deprecation feature at all. I saw a post from someone asking about deprecating one's own packages in ProGet, but I'm wondering about the handling of deprecated external packages. Would it be possible to have the follwing features in ProGet:

    1. Display deprecation info in Proget
      At the very minimum, the package’s deprecated info should be shown at the package’s info page. This includes any additional info that the package’s maintainer provides, e.g. a custom message and a link to an alternate package, if provided. Compare the info shown for Microsoft.AspNetCore in ProGet and on nuget.org:
      ProGet Deprecated package info ProGet.PNG
      ProGet Deprecated package info nuget.PNG
      Optionally, the info could also be shown in the search results (see nuget.org as an example):
      ProGet Deprecated search results.PNG

    2. The deprecation info should be visible in Visual Studio / dotnet.exe
      Visual Studio warns users if they use deprecated packages when connecting to api.nuget.org:
      ProGet Deprecated VS nuget.PNG
      However, when connecting to ProGet, no warning is shown:
      ProGet Deprecated VS ProGet.PNG
      My guess is that this is another part of the nuget API, that is yet to be implemented by ProGet (like the vulnerability info, see PG-2359).

    3. SCA Reporting should report deprecated packages
      Just like warnings about vulnerable packages or packages with unwanted licenses, SCA reports should show a warning when deprecated packages / package versions are used by a release.

    4. Handle unlisted packages like deprecated packages
      ProGet allows for packages to be unlisted by user. In those cases, it would be nice if the features mentioned above could be applied to unlisted packages as well (display warning in Visual Studio, issues in SCA reports).

    I'm aware that this is probably not a trivial request, because NuGet packages can become deprecated after they have been cached by ProGet, in which case ProGet probably won't update the package's metadata. However, there are already some maintenance tasks running regularly within ProGet (like PackageAnalyzer), so maybe it would be possible to regularly check if if the metadata of cached packages is still the same? Or maybe such an update-task actually already exists?


  • inedo-engineer

    Hi @sebastian ,

    In ProGet 2023, deprecation information will be shown on the package page and through API:

    d7a1e1be-98fe-49f7-a604-471b84b175e3-image.png

    The information is passed through connectors and can be set on local packages on the package status page:

    3c752df7-cfd1-46ae-a9ef-5e08b56f09d0-image.png

    They should also show up as issues in SCA reports.

    However, as you noticed, it is server-side metadata (like listing status, download count, package owners, etc.), and we don't have any mechanism to "sync" server-side metadata from connectors at this time. That may come in ProGet 2024 but it's not trivial to generalize.

    However, you could probably write a script that uses the new Common Package API to easily retrieve packages from a feed, check their status on nuget.org, and update deprecated info.

    Best,
    Steve



  • Hi @stevedennis

    Thanks for your reply. I tried to get the deprecation info into ProGet to see how things look like in VS and in the SCA reports, so I deleted the package from my example above from the cache using the "Delete Cached Package" button. Once the package was deleted, I indeed saw the deprecation info on the package's info page:

    Inedo 3855 Non Cached.PNG

    However, once I downloaded the package from ProGet, it seems the deprecation info was lost:

    Inedo 3855 Cached.PNG

    Same goes for the package from your example (which had not been previously downloaded and cached on our ProGet installation): Once I downloaded the package, the deprecation info is gone. Does that mean that ProGet does not copy NuGet's deprecation info when downloading a package, even when that status is already set at the time of the download? Is this a bug or intended?


  • inedo-engineer

    Hi @sebastian ,

    This behavior is "intentional" but not ideal; we simply add the package file to the feed but don't set any server-side metadata properties.

    This seems like something we should change, so I logged PG-2426 to address this; perhaps we'll get it in the next maintenance release. It seems relatively simple, but I didn't look too deeply

    Best,
    Steve



  • Hi @stevedennis

    Some additional info: I deleted the package from ProGet's cache again to test the SCA reporting. However, even though the package's info page now shows the deprecation info correctly, I don't see any warning in my SCA report. I then downloaded the package again and wanted to set the status manually to see if that makes any difference. However, I'm somehow too blind to find a "set status" option. I know that when a package has a vulnerability, I can set its status by clicking on a link within the vulnerability message, but I simply can't find such a link/button for a package that doesn't have any vulnerabilities.

    One more thing: you mentioned writing our own "package updater" script using ProGet's Common Package API. Is there a way to list all packages that are cached by ProGet? Because those are the only ones I'd want to check for new metadata. Checking every single package on nuget.org and comparing its data to the data provided by ProGet (or vice versa) would be unfeasible.


  • inedo-engineer

    @sebastian it looks liike the "set package status" only appears for Local Packages...

    When testing this, I noticed that there was a bug with the release analyzer; basically it's a constraint that wasn't properly added. We'll fix this via PG-2428, but you can just run this script - and deprecated packages should show up. At least on my machine :)

    ALTER TABLE [ProjectReleaseIssues23]
    DROP CONSTRAINT [CK__ProjectReleaseIssues23__IssueType_Code]
    
    ALTER TABLE [ProjectReleaseIssues23]
    	-- [V]ulerability, [M]issing Package, [O]utdated Package, [L]icensing Issue, [D]eprecated
      ADD CONSTRAINT [CK__ProjectReleaseIssues23__IssueType_Code]
    		CHECK ([IssueType_Code] IN ('V', 'M', 'O', 'L', 'D'))
    
    

    Is there a way to list all packages that are cached by ProGet?

    That API will allow you to list all packages in a feed; you'd basically want to query NuGet for each of those packages.



  • @stevedennis
    Just wanted to let you know that I tested this with 2023.13 and both issues (PG-2426 and PG-2428) do indeed seem to be fixed with this version. However, it took some time for the package's page to show that the package has been deprecated after I downloaded it. I guess the package analyzer had to run to correctly show the package's state?

    What's left is some kind of periodic check for updates on a packages' metadata after it has been downloaded. This would be really useful (doesn't have to be daily, once a week would suffice).

    BTW: We are currently looking into the API approach that you suggested and one question came up: Is there a way to add custom scheduled jobs to ProGet (like the UpdateChecker or PackageAnalyzer tasks)? If not, could something like that be added via the Inedo.SDK in the future? I know we can just trigger it with a generic job scheduler, but it would be nice to have all ProGet-related maintenance jobs in one place.

    Cheers,
    Sebastian


  • inedo-engineer

    Hi @sebastian

    There is no plan to add user-configurable scheduled job capabilities to ProGet, and it's unlikely we would consider that since they are really hard to support. We do have our Otter product that's designed for that 😉

    However, in ProGet 2022, we considered a periodic "check" for packages in a feed against the source; the use case was "is a newer patch version available" - and if so, then an issue would be raised about using an out-of-date package. We obviously didn't implement that.

    But it seems we could take a similar approach and then also check for unlisting/deprecation as well. This might be something that comes up in our ProGet 2024 planning.

    But in either case, it still involves lots and lots of web calls to check each package against the source - so I would start with a a script and see what you find out.

    Thanks,
    Alana


Log in to reply
 

Inedo Website HomeSupport HomeCode of ConductForums GuideDocumentation