@atripp @joshuagilman_1054

TIL that PowerShell can use internal CLR generic reference type names like that! But really, please don't do that...

• [System.Nullable``1[[System.Int32]]]
• [Nullable[int]]

... much easier to read

You can ignore this error; for whatever reason, the NuGet client unexpectedly terminated the connection, and the result was that ProGEt stopped writing bytes. Not really anything to worry about.

The diagnostic center isn't for proactive-monitoring, more for diagnostic purposes. So ulnless users are reporting a problem, you don't need to check it.

Hi @andreas-unverdorben_1551 ,

npmjs.org primarily serves static content and runs on massive server farms running in Microsoft's datacenters.

Your ProGet server is much less powerful and does not serve static content. Not only is every request is dynamic (authentication, authorization, vulnerability checking, license checking, etc), but most requests (such as "what is the latest version of package X") need to be forwarded to npmjs.org and aggregated with local data.

So, a much less powerful server doing a lot more processing is going to be a little slower ;)

Running ProGet in a server cluster will certainly help.

Cheers,
Dean

Hi @kichikawa_2913,

We see multiple connectors pretty often, and it rarely presents a problem.

The main downside comes in the overhead of aggregation; for some queries like "list all package versions", each connector will need to be queried and have the results aggregated. So it could cause performance issues for for very high-traffic feeds - at least that's what we see on the support side of things.

However, if you plan on using a package-approval workflow, then it won't be a problem, as your approved-npm feed wouldn't have any connectors.

Hope that gives some insight,

Dean

@joel-shuman_8427 thanks for the heads up!

I just updated it
https://github.com/Inedo/inedo-docs/blob/master/CONTRIBUTING.md

Hi @jimbobmcgee ,

Thanks for all the details; we plan to review/investigate this via OT-518 in an upcoming maintenance release, likely in the next few two-week cycles.

-- Dean

Hi mwatt_5816,

BuildMaster does support "release-less" builds, though you may need to enable it under the application's Settings > Configure Build & Release Features > Set Release Usage to optional. That will allow you to create a build that's not associated with a release.

It's also possible to do "ad-hoc" builds (i.e. builds with no pipeline), but we don't make it easy to do in the UI because it's almost always a mistake (once you already have pipelines configured). So in your case, I think you should create a secondary pipeline for this purpose.

-- Dean

Hi @mmaharjan_0067 ,

It sounds like you're on the right track with researching this; your reverse proxy is definitely "breaking things" somehow.

Based on what you wrote, it sounds like your reverse proxy is terminating the request because there's no output from the server after a while. The "no output" is expected, since assembling the upload takes quite some time, and that's likely where the "operation cancelled" would be coming from.

I would look there and see if you can adjust timeouts. As for pgutil, here's the code used to perform the multi-part upload:
https://github.com/Inedo/pgutil/blob/thousand/Inedo.ProGet/AssetDirectories/AssetDirectoryClient.cs#L197

-- Dean

Hi @Nils-Nilsson,

Thanks for the report; this was a trivial fix and I just committed the change to PG-3138 , which will be in the next maintenance release (Oct 24).

As an FYI, if you uncheck "Restrict viewing download statistics to Feed Administrators" on the Feed Permissions page, then error shouldn't occur.

-- Dean

Hi @d-kimmich_0782 ,

This behavior is by design; the "publish date" in ProGet 2025 and earlier is whenever a package is added to a feed. This means that, even if a package was published to NuGet.org 3 years ago, the "publish date" will be whenever it was first cached.

However, in ProGet 2025.14 and later, you can change this behavior under "Admin > Advanced Settings > Use Connector Publish Date". This will be the default behavior in ProGet 2026.

This is being done for a similar set of rules you should investigate, which we call Recently Published & Aged Rules :
https://docs.inedo.com/docs/proget/sca/policies#recently-published-aged-rules-proget-2026-preview

-- Dean

Hi @certificatemanager_4002,

I'm not sure I totally understand the question :)

The ConnectionString property is marked as encrypted, which means that ProGet's Encryption Key will be used to store it to the database as encrypted, and obviously decrypt it.

But this should happen automatic, when using the API or UI to save the settings.

-- Dean

Hi @ybaskar-temp_3339,

Going off of memory here (this was like 10 years ago), but I believe that BuildMaster v5 would hide legacy options unless there was already legacy data. Since there's no legacy plans there's no button.

However, it still should be possible if you can find the url of the page to navigate to. I would check other apps for that option, inspect the url, and just replace it with your applications Id.

Let us know if that works!

-- Dean

@pg_user_8607 very cool, great practical use of the new ".cs scripts" type applications! I think this could make a nice blog post... I'll point this to our technical writers!

Hi @devops_8569 ,

I'm afraid this is a known limitation issue with Maven versions in ProGet for now.

Long story short, ProGet followed these versioning specifications:
https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855

However, some packages did not follow those specifications but instead relied on undocumented quirks (bugs?) in the Maven version parsing. These are now somewhat documented: https://maven.apache.org/pom.html#version-order-specification

It'd be nice to fix, but it would require a risky, non-trivial rewrite of our Maven version parsing to solve this. So far as we can tell, the only consequence is that a small number of vulnerabilities yield false positives. So, it's not a priority.

In ProGet 2026, we are substantially changing vulnerability management so it's likely these false positives won't be an issue anymore. For example, PGV-2314320 would be rated as a PVRS Category 2 for most environments.

We'll evaluate / explore this after getting feedback from users in ProGet 2026, and whether they think it's worth us investing the time/risk to address this limitation.

-- Dean

Hi @parthu-reddy ,

Thanks for the additional information. Thinking about it further, I suspect this was a temporary network outage. It could have been DNS related, or who knows what.

As for your configuration...

5000 is definitely too high; set this towards 100-500 max. If you're working on a load-balanced cluster, this should be done at the load balancer instead.

I was incorrect about api.nuget.org, that is also used by the V3 API. I thought it was only V2. So please disregard.

It's unlikely metadata caching will help, but you could try it. That's a relatively short-lived cache meant for traffic bursts, and it's not really going to help with a network outage.

-- Dean

Hi @parthu-reddy,

Thanks for the detailed investigation notes. From what you've described, the behavior doesn't appear to be related to SQL Server locking. It's most certainly related to blocking/waiting on the 200+ outgoing connections to receive a response from api.nuget.org.

If api.nuget.org is running slow, then ProGet will run slow. There's really no way around this when you use connectors, as ProGet is effectively forwarding client requests.

Most likely, someone or some build server is making legacy/V2 NuGet API requests (they look like ODATA/SQL queries on the url), and those are being forwarded. The V3 requests are just JSON files.

-- Dean

Hi @0xFFFFFFFF,

Thanks for the detailed write-up and explanation.

It looks trivial to add size and upload-time. Adding versions is probably simple, assuming it's just an array of distinct version numbers (we already have all the "packages" in context).

It's probably fine, but just to be safe we will do this in ProGet 2026, given some of the subtle behavioral changes you mentioned ("tools like uv to make use of heuristics to speed up downloads"). For someone with an overloaded server, that might "put it over the edge".

ProGet 2026 may be ready by the end of the month, so it's not so far away.

-- Dean

Hi @Nils-Nilsson ,

Thanks for the bug report; it seems to issue is on the "view" page, and it's mistakenly editing the wrong data.

PG-3258 will fix this in the next maintenance release (April 17), but a prerelease is now available (inedo/proget:25.0.26-ci.6) if you'd like to try it.

-- Dean

@rcpa0 thanks for letting us know; we'll try to fix this next time we make some changes to pgutil it should only print "Version is not a valid semantic version." or something

Hi @geraldizo_0690 , unfortunately we didn't get a chance to review this for the last maintenance release, but it'll be in the next one (April 17) via PG-3257. It's also available via prerelease if you'd like (inedo/proget:25.0.26-ci.5)

-- Dean