Makes sense, thanks for the quick fix.

Cheers

I don't think there is a standard for that, it probably depends on the markdown editor where it puts its assets.

The README.md had a link like that:
![image-20220120113554562](README.assets/image-20220120113554562.png)

The reason I reported it is, every time some clicks on such a "broken" package, the Diagnostic Center is spammed with these pointless exceptions.

When those packages are coming from a 3rd party feed, then there is no real way to fix it other than praying a new version of that package is released.

Occurs in: 2024.2 (Build 2)

On the /licenses/types page when using the add license type button, the modal dialog says a new license with SPDX identifier could be added.

But after adding the license the SPDX ID is empty.
Additionally the License code: field is shown twice in the UI.

Maybe it would make sense to use the Edit License Definiton UI also for adding new licenses? That would save the user adding only partial information and then having to search the added license again to complete the input. Just a thought..

I managed to implement the workaround for the uncached packages.

Right now I am doing the following:

1. API call to $"api/sca/builds?project={projectName}&version={version}"
   • Parse the build Id out of the ViewBuildUrl property
2. API call to native API $"api/json/Projects_GetBuildInfo?ProjectBuild_Id={projectBuildId}"
   • Cross reference ProjectBuildPackagesFeeds with ProjectBuildPackagesExtended to find out which packages could not be mapped to feeds
3. Call to the download button URL $"nuget/{feedName}/package/{packageName}/{packageVersion}" for each package that could not be mapped to any feed
4. API call to ($"api/sca/analyze-build?project={projectName}&version={version}" to update the build

While it does work, I'm not fully happy with the implementation and would like to ask for some improvements to the regular API.

Compliance information in PackageInfo

Right now the PackageInfo object does not contain any information about compliance violations. Would it be possible to extend it with the warnings that are shown in the compliance column of the /projects2/packages page?

Ideally, it would be some sort of enum, that has atomic values for all the known violations and can be filtered easily. This would help to to avoid the call to the native API in step 2, which as far as I understand you don't recommend using anyways.

{
  "purl": "pkg:myGroup/myPackage@1.2.3",
  "vulnerabilities": [],
  "licenses": ["MIT", "Apache-2.0"],
  "compilanceWarnings": [
     "PackageNotFound",
     "NoLicenseDetected",
     "Deprecated"
  ]
}

What would also be nice to have is atomic values for the package name and version, so one doesn't have to parse it out of the purl.

Download Package API behavior
Right now the /api/packages/MyNugetFeed/download?purl=pkg:nuget/MyNugetPackage@1.0.0 API returns 404 when trying to download a package that is not cached yet.

As a workaround I am using the URL of the download button used in the UI, but I would prefer to use a proper API endpoint that has more chances to be stable in the future.

I think it would be good if the download API could be changed to also trigger package downloading and caching from connectors, so basically the same behavior as the endpoint behind the download button.

Occurs in: 2024.2 (Build 2)

The following exception shows up in the Diagnostic Center every time when viewing a NuGet package which contains a README.md which in turn links to images that were not included in the package:

An error occurred in the web application: image-20220120113554562.png not found.

URL: https://xxxxxxxxx/feeds/xxxxxxxx/xxxxxxxxxx/README.assets/image-20220120113554562.png
Referrer: https://xxxxxxxxx/feeds/xxxxxxxxx/xxxxxxxxx/3.0.0
User: xxxxxxxxxxxxxxxxxxx
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
Stack trace: at Inedo.ProGet.WebApplication.Pages.Packages.PackagePageBase.CreateChildControlsAsync()
at Inedo.ProGet.WebApplication.Pages.ProGetSimplePage.InitializeAsync()
at Inedo.Web.PageFree.SimplePageBase.ExecutePageLifeCycleAsync()
at Inedo.Web.PageFree.SimplePageBase.ProcessRequestAsync(AhHttpContext context)
at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)

So this is a strongly subjective thing, but I was wondering why the default font size was changed from 14px to 16px.

I've been looking around other UIs (GitLab, TeamCity, Google, this forum, etc.) and the default text size seems always to be around 14px.

Maybe I'm off here, but 16px somehow it looks "wrong" to me.

Would love to hear other opinions about this, so feel free to jump in.

**edit
Forgot to mention, the new Karla font itself is perfectly fine, just talking about the size.

@stevedennis

Thanks for the updated version - it works smoothly now.

Unfortunately this difficult to debug on its own, and it will be impossible to debug w/o the database itself, but if you're comfortable with SQL feel free to modify or tweak. It's not an easy script :(

Yea, the size and also the fact that it deletes things puts that out of my comfort zone. ;)

We haven't yet run this against all customer databases yet, but it's our list this week. If you haven't sent us your database already, please do :)

You can find our database in EDO-10311, I have also extended the expiration date in case you need to redownload.

Executing a revised version manually is perfectly fine for me, if you decide not putting it into the 2024.2 release. I'd appreciate clear communication what should or should not be done with the next update to get this fixed.

Thanks for the effort.

Thanks for the script, it does indeed find a few things.

I have an error all the way at the end of the script. Is this because I ran it on a 2023.32 database and it is only supposed to be run on a 2024.x database? (Only used DryMode so far)

Deleting Duplicate Ids...
Error: The DELETE statement conflicted with the REFERENCE constraint "FK__FeedPackageVersions__PackageVersionIds". The conflict occurred in database "ProGet", table "dbo.FeedPackageVersions", column 'PackageVersion_Id'.
[2024-04-29 17:57:00] 206 rows affected in 356 ms

The reason I'm asking is that I'm not quite sure how to proceed with our instance.

I want to avoid running into the same exceptions that were mentioned above. From the changelog it was not quite clear to me if these issues have been addressed in code or we really need to run a cleanup script before upgrading.

From what I've been told, our database has duplicates that only differ by casing of the package names. So, if there is any script to identify or clean these duplicates I'd be happy to give it a shot.

Is this issue addressed in the 2024.1 release?

A clean-up script, that is supposed to remove the duplicate entries, was mentioned to be included in a post 2024.0 release, but I could not find anything in the changelog.

@atripp said in NuGet no longer works after upgrading to 2024:

Offhand, I believe it's a result of "bad data" (duplicate packages) that are in your database, and it's the same issue behind here: https://forums.inedo.com/post/15730

Hi Alana,

before we run into the same thing, is this by any chance the same "bad data" you mentioned in EDO-10311?

We're in the final stretches of ProGet 2024 now (looks like we're on ci-27 as of this morning); you're welcome to try it, we've been using it for a bit ourselves. It seems to mostly work.

I've been looking into ci-30 a bit, since I had some issues with the SCA API, but it seems they still persist in this version.

• https://docs.inedo.com/docs/proget-sca-releases-get

  • I cannot get the /api/sca/releases?project= to work, I always get some Persisted object is not a ProjectReleaseConfiguration. HTTP 500 error.

  • According to docs ReleaseInfo does not contain the id, it would be good to have that there. From what I understand the id is needed for the /api/json/Projects_GetBuildInfo?ProjectBuild_Id= API

  • Few docs issues

    • releases endpoint should probably be builds now
    • /api/sca/releases?name= is mentioned a few times but the parameter should probably be project

• Export SBOM for both formats is still broken for me in this version.

• Version number is cut off in the UI
  

• The SCA Events seem quite granular
  
  Do these really fire for every single "noncompliant package", "vulnerability detected" or "issue opened"?
  I was hope something along the lines of "Build Added" that fires after a new SBOM was imported, containing the build id, project name and build version

Thanks for squeezing these all into the upcoming release.

On semi-related notes:

Does it make sense to give feedback about SCA 2024 issues for the 24.0.0-ci.5 version, or will there be a RC before the release?

I'm afraid this is a bit too granular for us now, but it's something we can consider re-evaluating down the line, especially as we will likely want to add specialize permissions for projects, policies, etc. We expect that will happen later in the year, after ProGet 2024's new features get more adoption. We'll see if anyone else requests package-level permissions, etc.

Thanks for the feedback, let's see if there is more demand.

As for the Advanced, I put a note in ProGet 2024's final touches to address that. Honestly I thought those were only on Debug builds only, but clearly not... thanks for reporting!

Glad to hear it is just an UI issue, I was worried users could mess with metadata.

Cheers

As of 2023.32 the right to mark a package as deprecated is tied to the Unlist Package permission.

This permission also allows modifying download rules and unlisting, which is not something we want developers to be able to do.

We would like to have a dedicated Deprecate Package permission that just allows that and nothing else.

Thank you for considering.

Also a question:

The text boxes Advanced tab on the Set Package Status popup seem to suggest that publish/download metadata could be changed here, but changing anything has no effect.

What is the intention here? These text boxes should probably not be there?

I think it makes sense to put the SCA 2024 Preview UI feedback in a different post, or this one will get too long.

Here a some of the issues my colleagues reported to me.

Version: 2023.32.
For a user with the following permission set:

1. Top menu bar - Replication /

Link leads to 403 page and exception is recorded in admin log.

=> The replication link should be hidden if the feature is not licensed or at least be moved into the admin panel. A user without permissions should never be able to see that link, since they usually have no business configuring it.

2. Packages and Container page /packages and/containers

The bulk edit menu is always visible, clicking on it shows a menu with delete or promote option. Selecting Delete selected results in no action at all, which is misleading.

=> The "bulk edit" link should be hidden for users that do not have delete or promote permissions in any feed.

What might be a bit more tricky to handle is the case when users have local feed permissions. Some feedback to the user about what did or did not happen would probably be a good start.

3. Package page /feeds/nuget-feed/package-name/1.0.0

The Repackage Package and Reanalyze Packge link both lead to 403 pages and exceptions are recorded in the admin log.

=> Both menu items should be hidden

4. Package metadata page /feeds/nuget-feed/package-name/1.0.0/metadata

details link causes 403 and exception is recorded in admin log.

=> There should probably be two links "view" and "edit"
View should be available for everyone regardless of permission, since they can just navigate to the file tab and find the embedded license file directly. Edit should only be visible with appropriate permissions.

My colleagues have reported a few issues with the ProGet UI to me. Usually it revolves around them seeing a link or a button but when they click that element, either nothing happens or they receive a 403 error, either in-page or as popup.

From permission point of view this makes totally sense, as they are trying to access resources which they are not authorized for.

I tend to agree with them that from a UI/UX perspective this is a bit annoying.

From what I could gather from the ProGet UI is that the general design philosophy seems to be to hide elements (links, buttons, pages, panels, etc.) when a user does not have the appropriate permissions.

Is my assumption here correct and does it make sense for me to report those issues that my colleagues and I have found?

Looks like success!

Thanks for addressing this so quickly.

Updated my test instance from SQL Server 2016 - 13.0.4001 to 13.0.6435.1, which should be the latest if one ignore Azure features - still no luck.

This is what the activity monitor looks like during job execution. The average seems to be around 900-1000 batch requests/sec. No idea if that is normal or resonable.