I believe this has already been fixed as part of PG-2343 in v2023.3, which we are releasing today. In addition to being slow, the NuGet queries responsible for handling latest versions could return a lot more results than necessary. It didn't lead to incorrect behavior (except with counts) as we still validate and filter results in the frontend, but did cause problems like this.

This is now fixed in 2023.3, which is going to be released later today. Thank you!

@rie_6529

We've identified issues in the queries used for fetching the latest versions of NuGet packages in a feed that are causing these problems. We will include a fix (PG-2343) in tomorrow's release of ProGet 2023.3.

Thanks for the report and investigation!

Hi,

We've identified the issue causing the .snupkg push to fail (PG-2340). A fix will be included in tonight's hotfix release (v2023.2).

We haven't been able to reproduce issues with feed re-indexing deleting packages. I agree that that is unsettling. Did you have the "delete missing packages" option selected for the re-index?

-Greg

Hi,

Thanks for the bug report. This was caused by a change in the way we're handling npm package scopes. We have fixed it as PG-2338 for ProGet 2023.2, and we plan to release it later today.

Note that you will need to rename your storage folder back after upgrading - the @ is supposed to be there.

-Greg

Hi,

I thought we had already fixed this, but I was thinking of a fix we applied for RPM package uploads. It's a regression in a core platform library that has bitten us more than once. Fortunately, the fix here is exactly the same (logged as PG-2307). We'll get the fix in v2022.25 for sure. Originally we had planned to release on Mar 24, but we may move it up to this Friday instead to get this resolved more quickly.

-Greg

It turns out the problem was in the code that adds the package record to the database was using the raw version string instead of the normalized version, which causes a lot of problems as you can see. We've fixed that in PG-2278, and this fix will be in ProGet 2022.20 to be released this Friday. Unfortunately it won't fix any invalid records that have already been created. Time permitting, we will try to get a job in that can be run to fix nonnormallized versions in the database, but if it doesn't make it in this release you'll need to manually remove or update that row in the SQL database. Let us know if you need any assistance with this.

Hi Justin,

Looking at the error, I'm wondering if the directory is actually too long for git, and it's reporting the wrong error message. You could try changing the agent temp directory in the %PROGRAMDATA%\Inedo\SharedConfig\InedoAgent.config file by adding a <BuildMasterRootPath> element to the configuration file with a shorter path like C:\Temp.

However, if you just need to run on the local server, there's no reason not to just use the local agent instead - it can do everything the Inedo agent can do.

-Greg

I've logged this as an issue in the upack repo, and we should have this included in an updated version within a day or two.

Thanks!

@jeff-peirson_4344 - I just ran a test and verified the behavior. ProGet does the following on startup to determine the connection string (in this order):

1. look for SQL_CONNECTION_STRING environment variable (this was the old documented name)
2. look for PROGET_SQL_CONNECTION_STRING environment variable
3. look for PROGET_SQL_CONNECTION_STRING_FILE variable

The first of those with a non-empty and non-whitespace-only value is used. The connection string file requires only read access, and must be plain text containing only the connection string with no additional quoting or escaping. Empty lines are ignored - the first non-empty line is used as the connection string, and any trailing newlines are ignored.

Our Dockerfile does specify a default PROGET_SQL_CONNECTION_STRING, so you may need to override that to be empty. Perhaps it would make more sense if we checked for the file first - I'll discuss that with the team.

Hope this helps!

Sorry for the delay - this is logged as PG-2195 and will be fixed in tomorrow's releases of ProGet 2022.7 and 6.0.20.

Hi @pariv_0352

We've updated ProGet 2022.6 to be more permissive and allow the . in non-semver2 NuGet versions. v2022.6 will be released on Friday.

Thank you!

Hi @brett-polivka,

We've published v2.0.1 of the Azure extension for ProGet, which should resolve this issue. You can install it from the Admin->Extensions page.

Let us know if you are still having the issue after updating the extension.

Thank you!
-Greg

Hi,

This is a regression - pdbstr.exe is used to provide source server support for legacy symbol files. I've logged the issue as PG-2159 and it will be fixed in ProGet 2.0.2, scheduled for release this Friday.

Thank you!

Hi,

It looks like on close inspection, conda build omits the summary if it has any non-ascii characters in repodata.json. As of v6.0.16 (see PG-2149) ProGet will now do the same.

Thanks for the bug report!
-Greg

Hi,

This was caused by a very trivial to fix bug (logged as PG-2128) - thanks for reporting it! The fix will be included in ProGet 6.0.12 which is being released on Friday (Apr 15).

Thank you!
-Greg

Hi,

Thanks for reporting this. We've now fixed this internally as PG-2105 - it will be included in this week's 6.0.9 release, scheduled for Friday.

-Greg

Hi,

Thanks for the bug report! We've logged and fixed these as PG-2098 and PG-2099. Note that due to limitations in how that dependency table is built, it's nontrivial to have it take you to the latest package that satisfies the given range if it has an exclusive upper bound - but we have changed it to prefer linking to the upper version number if one is present.

-Greg

Hi,

Did the initial upgrade attempt fail, or did it appear to work but with the wrong directory?

What error did you get - are services/websites not starting?

-Greg

Hi @paul_6112 ,

That actually makes sense. We have an issue in our internal backlog to resolve high memory usage when a large number of agents are scanned just after an upgrade. I've published it as a publicly visible issue (BM-3758), and tentatively scheduled it for the next release.

-Greg