Hi @james-woods_8996 ,

Setting the ASPNETCORE_URLS is the correct way to address this; that troubleshooting guide is outdated (though it probably still works to write out the config file like that).

As far as I understand, this behavior has not changed in ProGet 2025 and has been the default behavior since ProGet 2022. We had considered changing the Linux ports to be 8624/8625 to mirror Windows defaults, but decided to just update the documentation to clarify.

Thanks,
Steve

@p-pelinski_1371 @pbe_9047 thanks for confirming that!

We will get this fixed via PG-3031 in the next maintenance release. You are also welcome to try the proget:25.0.3-ci.3 container image, which is building now.

Hi @mcascone ,

We don't have a single API method that can be used to delete all package versions from the API, but the foreach loop will do the trick!

I should add that I am doing this as the first stab at an attempt to automatically delete packages from a development feed, when the corresponding branch in github is deleted

I don't know the specifics/details of your use-case, but based on what I read, I'd recommend these guidelines:

• assuming: one GitHub repository, one project, one package you want to release
• use the same package name/group for all packages you create for this project, regardless of branch or development status
• create your "dev" packages using a prerelease version number, that has a sort of -ci.## version (assuming you use CI to build packages)
• embed the commit id and branch in your upack metadata file, for traceability
• if you want to see which branch the packages was created from using the version number alone, add a +branch metadata label to the version number for branches (don't do this for master)
• use repackaging and promotion to take your -ci packages to -rc to stable (and the desired feed)
• let retention policies automatically cleanup up the -ci packages

@phopkins_6694 perfect, just what I was looking for

I was able to reproduce this - searches via the NuGet API (which connectors use) will consider tags, while local searches seem to only be looking at names.

I'm not sure how long this has been the case, but we'll try to get it fixed soon. Unfortunately it's not a trivial fix, hopefully we'll do it via PG-3046, likely in the July 18 maintenance release.

Thanks,
Steve

@joshuagilman_1054 this is currently planned for 5.3.27 as PG-1934 (April 17) - we'll let you know if plans change!

Hi @brett-polivka,

I've added it to our Other Feed Types page, and linked this as the official discussion thread.

There's a lot of things to consider in developing a new feed type, but ultimately it all comes down to two things: (1) how much more value does this feature bring to our users, and (2) how many new licenses of ProGet would this feature sell.

The second question is where internal market research comes in, but we would love your opinion on the first question.

Here's a nice and simple way to help understand value: how much more do you suppose your company/organization would pay for this feature if it were available as a hypothetical add-on? $100/year? $1,000/year? $10,000/year? Etc. And why? What time is it saving, risk is it mitigating, etc.

The second part of the value equation is how much effort will it take, technically speaking. It's more than 15 minutes obviously, but is it 10 hours? 100 hours? Etc.

On the plus side, the package format seems to be documented pretty well. However, the registry API has a huge red flag:

The index key should be a URL to a git repository with the registry's index.

Does this mean their API is Git-based, and we'd need to first add private Git repository hosting to ProGet? And did they test it with private/authenticated Git repositories, or just their public (probably GitHub) repository?

@mmaharjan_0067 we'll see how we can improve this while we work on PG-3034

Hi @kichikawa_2913 ,

I think it's this way for "historic reasons" - mostly all the other feed types came later, and it seems no one ever changes these paths or noticed.

Easy enough to make it configurable, but can you share your use case? Why do you want to use something other than a single root path with all of your packages?

Anyway I added a feature for this, and we should be able to get it in the next maintenance release PG-2006

Cheers,

Steve

Hi @benjamin-soddy_9591,

No problem "resurrecting" topics! We definitely want to hear from users about feedback/feature requests.

We still haven't had anyone else ask for deprecation since this request, but I wonder if there's a better solution to solving your challenges than this feature. It sounds like you want to increase governance of your NuGet Packages, potentially with some sort of compliance in mind.

The dotnet list package --vulnerable is probably not what you want for your organization; NuGet's Built-in Vulnerability Scanning is really limited, in part because it only reports on a fraction of known package vulnerabilities (164 as of today). It also won't block packages that you deem problematic, unlike ProGet's feature.

The same is true with dotnet list package --outdated -- it's probably not what you want, because it relies on developers to have to know (1) to run the command, and (2) know what to do if there's an outdated dependency.

There are better ways to manage third-party packages (see How to Create a Package Approval Workflow for NuGet), and you'd better served knowing who's consuming outdated packages (see Use Package Consumers to Track Dependencies

Just some thoughts; like I said, we haven't had any demand for this feature, but these are proven solutions for improving governance of packages as organizations grow/expand their NuGet usage like you are.

Cheers,
Steve

@jfullmer_7346 this is a bit tricky behind the scenes but hopefully will be resolved with PG-3047 -- which we hope to get in the next or following maintenance release

Hi @daniel.mccoy_4395 ,

This is how unlisted packages are designed to work; it's just a flag in the metadata, and clients will treat it however they'd like. Visual Studio hides them but lets you download them, ProGet shows them with a little "unlisted" icon.

As for the download error, the 400 sounds like you've configured "download blocking" perhaps? Check the feed's policy settings.

We generally don't recommend configuring download blocking, but using pgutil builds scan instead; see https://guides.inedo.com/vulnerability-management/containment/

Hope that helps,

Steve

Hi @olivier-piron_7128 ,

I'm afraid this behavior is somewhat expected because TRK.0 is not a valid version number.

ProGet has some limited support for invalid version numbers, but this use case falls into one of those unsupported cases.

The reason is that ProGet is "package server" (as opposed to a file server), and all of the maven-metadata.xml files are generated by ProGet, on demand, based on items in the database. Uploads of maven-metadata.xml are simply ignored.

Compare this to Nexus (a file server), which serves the client-uploaded maven-metadata.xml files, and whatever other items were uploaded to whatever directory.

TRK.0-SNAPSHOT is technically a valid artifact name but an invalid version number, so it's treated like an artifact. And, since there are no releases of that package, you get a 404.

In this case, we would suggest you to switch to using actual version numbers. My guess is that TRK.0 is some kind of work-around for something. You could instead do 9999.9.9 or something, if you needed that kind of work-around.

Hope that helps,
Steve

Hi @jeremy-oaks_9309 ,

Just wanted to respond to this real quick:

I have ~80k packages (~600GB) -- so we're opting for the stand-alone database for performance purposes

Based on this information we still recommend using the embedded database; it's almost always going to be more performant as well as simpler to maintain. 80k is not that many packages by any stretch.

While @pg_user_8607 is correct in that it's a bit easier to monitor database performance, investigate issues like bad queries, and do DBA maintenance tasks - that's all technically "our job". From a user perspective, the only required "database maintenance" should be backing up the files.

We certainly don't mind the help (and users like @pg_user_8607 have helped us out a lot!!), and it may be quicker if you "know what you're doing" to get to a root issue, since we're not all exactly experts at all these layers. But I just wanted to make sure you were aware of the pros-and-cons.

Thanks,
Steve

Hi @gbeckett ,

There are Feed Names (which you can configure) and API endpoints (which you cannot configure).

Our general guidance on feed names is internal-nuget or public-nuget, but we've seen cases where a lot of feeds are needed. I suppose tenant namespace like tenant1-nuget might work too. But like naming of everything else, you'll figure it out as you go.

While you can't change API endpoints, you could use the alternative /endpoints url if you really wanted. So instead of /nuget/public-nuget it would be /endpoints/public-nuget. Honestly I wouldn't bother... it's just a URL that no one really sees, and that's actually going to make it more of a pain to support. That's why we don't expose this.

Some ecosystems (like Docker) only support one registry per domain/port, which is why Docker feeds have no prefix. We work-around this by using namespaces.

One option I'm considering is layer a proxy in front of ProGet, to provide the URL rewriting to map to ProGet-compatible names.

Please don't do this :) We do not recommend nor do we support URL rewriting like this. People have figured out how to do it, but it causes lot of headaches and it will be painful to debug. Which is why we don't support it. Again... it's just a URL that no one really sees after you enter it.

Hope that helps!

Thanks,
Steve

Hi @brandon_owensby_2976,

I wasn't able to reproduce this issue, but looking over the code, I can see a few scenarios in which "not configured to allow access to encrypted values" will trigger, even if that's not accurate. It's not trivial to rewrite that to provide a more accurate error message or credential resolution, so we'll add this to our BuildMAter 2027t roadmap and review it more closely then.

In the meantime, I would just use a variable and duplicate the information.

Thanks,
Steve

Hi @brandon_owensby_2976 ,

You are correct, the $BranchName function is a build-information function that provides which branch a build was created from. It's a slightly different concept than the "default branch" that is associated with a release.

If changing your workflow to align with more standard practices isn't in the cards, then you may want to create a custom extension that will allow you to create your own variable functions and operations. This will make adding things like this easy and if it's something we think is generally useful, then we can generally add it in.

Although it's not supported in the SDK, if you take a reference to the core assembly (buildmaster.dll), you can invoke database commands like Releases_GetRelease to find that information easily.

Thanks,
steve

Hi @andreas-unverdorben_1551 ,

I'm afraid this is a problem with our upstream source (GHSA). Long story short, the datafile is incorrect and does not specify a range.

We do not have any plans to build a system/module that allows us to "override" data in the upstream datasources at this time, so the only way we can really address it is by fixing the upstream source.

I believe the best route to do that would be to submit a pull request to the GHSA repository against the related datafiles (e.g. GHSA-4r6h-8v6p-xvw6.json)

In this case, they are missing a "fixed" event in the range:

      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0"
            }
          ]
        }
      ]

Here's what it needs to look like:

      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": " 0.19.3"
            }
          ]
        }
      ]

Thanks,
Steve

Hi @brandon_owensby_2976 ,

You can configure release settings on an application-by-application basis under the Settings tab. In this case, you'd set Release Usage to be Optional or Disabled.

If Release Usage is set to Required, users must select a release when creating a new build; this was the deefault in older versions of BuildMaster.

https://docs.inedo.com/docs/buildmaster/modeling-your-applications/buildmaster-releases

Cheers,
Steve

@Nils-Nilsson excellent, let us know as you have other feedback too! This is definitely an area we intend to keep improving in throughout ProGet 2026+

Hi @carl-westman_8110 ,

Thanks for sharing that. This isn't a symptom of "server overload" that we've seen before.

The error you shared is occurring on Feeds_GetFeeds, which is definitely not an intensive query, and I would not expect that to be timing out at all. It's just SELECT * FROM [Feeds].

However, that's a similar symptom to the "AzureSQL resource throttling" that we've seen on other users: another query is being throttled (for example, something that joins on [Feeds]), and that is causing a cascading impact on other queries.

We don't have enough information to say that's the case here. But, an easy way to test would be to up your DTUs substantially.

Otherwise, the next troubleshooting step is to try to identify the cause of the timeouts, which involves looking at HTTP Access logs and jobs occurring around the same time under Admin > Scheduled Jobs.

Thanks,
Steve