Hi @scott-wright_8356,

This is usually due to a networking error; it may also be resolved by restarting. It's also just something you can ignore. The service messanger isn't very important in ProGet.

Best,
Alana

Hi @mahdy-merry_6333 ,

It's possible, and you can do this by creating a second feed that effectively proxies the first feed and uses disk storage. You could use a Connector on the two feeds or REplication.

Cheers,
Alana

Hi @scott-wright_8356 ,

Thanks; it sounds like the underlying issue is indeed Google Android connector you added. I don't have an information or idea on why that might be the case... some third-party repos (Maven, PyPi, NuGet, etc.) are just really slow and buggy.

ProGet is basically acting like a proxy server here, so "garbage in, garbage out" applies - if the connector is slow and error-prone, then you will experience slowness and errors.

Sometimes third-party repos will create packages that don't follow the specifications but just happen to work in certain versions of clients. That could be what's happening here. In cases like that, we can really only address those on a case-by-case basis, and we'd need to know exactly how to reproduce the error and investigate it later.

Best,
Alana

Hi @scott-wright_8356 ,

I'm not sure, but based on this URL:
https://maven.google.com/web/index.html#android.arch.core:common:1.1.1

I can see that the POM for android.arch.core.common 1.1.1 is located here:
https://dl.google.com/android/maven2/android/arch/core/common/1.1.1/common-1.1.1.pom

So the base URL would be:
https://dl.google.com/android/maven2

That should work, since maven works by convention. You will not see a listing of artifacts unfortunately, since Maven does not provide an index. You just need to know the articats by name, then append maven-metadata.xml.

As expected, the metadata file for that artifact is here:
https://dl.google.com/android/maven2/android/arch/core/common/maven-metadata.xml

Cheers,
Alana

Hi @scott-wright_8356,

It's a bit hard to figure out how to help or troubleshoot with the information here, but a few key points:

• A "healthy" Maven connector doesn't really mean much; just that the URL can be accessed by the ProGet server.
• A Maven repository (like the one you are linking to) is just a "web file system" with url/folder based conventions
• A Maven "package" consists of a .pom file and zero or more other files (.jar); think of it liked an unzipped package that you can add/delete files from
• This is why you can't import only .jar files - you need the .pom file (which serves as the package manifest)
• Sometime marvin "packages" contain malformed .pom files that happen to work in some versions of the client, and ProGet will sometimes error on reading those; maybe that's what happening here

To help on this, we'll need to know specifically where the issue is and have instructions on how to reproduce it on a new feed/instance of ProGet.

First, I would start by trying to download the .pom file and .jar files from Google (like that gradle one you found), then upload them to ProGet from the Web UI. If that doesn't work, then we know the POM file is probably bad, and we can investigate it.

Next, I would try to pull the pom/jar from a connector. If that doesn't work (but uploading it does), then maybe the "API" for that repository is incorrect. And we can investigate it.

Best,
Alana

Hi @scott-wright_8356,

I looked into this further; for Maven feeds, the Connector Health Check simply queries the downloaded index. If there is no downloaded index, then it reports back as healthy. If there's an error with the index, it reports an error. However, most maven repositories don't have a downloadable index.

Anyway the health check is not very useful, and we plan to revisit the functionality in the future, since there's really no way to determine if ProGet can download an artifact unless you know the exact name.

Thanks,
Alana

Hi @m-karing_2439 ,

Unfortunately, this repository doesn't following PyPI repository conventions.

For example:

• No way to see latest packages (should be https://download.pytorch.org/whl/cu118/rss/updates.xml)
• Does not return anything for /simple listing (e.g. https://download.pytorch.org/whl/cu118/simple)
• Does not support JSON-based API to retrieve package metatadata

I guess it "happens to work" in pip , or perhaps they install a plugin that allows it to work... but ProGet is designed around PyPi repository specs. which is why a non-confirming download site won't work very well.
I'll add a note to investigate this further, but for the time being you should just download the wheels and upload them to a feed in ProGet.

Cheers,
Alana

Hi @Justinvolved ,

This is not uncommon with PowerShell; in general the processes will be closed, but there are enough scenarios with long-running/hanging PowerShell scripts where those processes will report termination but the process will not be terminated. So they can stick around

I'd recommend using the Inedo Agent instead, even if it's on the same sever. That gives better process isolation compared to the local agent, and you shouldn't see this behavior for too long. The local agent runs in-process.

Cheers,
Alana

Hi @akillen_5633 ,

Sorry on the slow response, but we're kinda stuck on this one; for some reason, the query to list packages is timing out. That's really unexpected, especially in 2023.31.

If it was related to heavy load, I would expect a lot more symptoms - like API calls, etc timing out. That doesn't seem to be the case.

The only thing that we can think of is that something is wrong with SQL Server, in so much as it needs some maintenance.:

• run exec sp_updatestats
• rebuild indexes (see https://docs.inedo.com/docs/installation-sql-server#advanced-maintenance)

We've also seen some old/unpatched versions of SQL Server cause strange performance problems due to some obscure bugs in SQL Server. So that's another thing to consider.

If that doesn't do the trick, you may need to dig in a bit deeper to figure out what's going on, and see what SQL Server is doing behind-the-scenes. Ultimately this is just executing the Packages_GetPackages stored procedure, which is basically just doing a straight-forward select on FeedPackageVersions_ExtendedWithMaven view.

Best,
Alana

Hi @chris-cantrell_1211 ,

We do not support nor recommend this type of configuration for a couple reasons.

First, it doesn't change the attack surface, since the APIs are already the "weakest link". The Web Site use cryptographically-secured authentication tickets with anti-CRSF protection. The API just requires an API key to access.

Second, it's confusing to end-users who are trying to troubleshoot why some urls aren't accessible. The API may provide them with a link (for example to a vulnerability in a package), and then it will give some kind of error because the page is blocked. This causes everyone a headache.

Obviously you can use a lot of tools to block/allow access to URLs, just not using ProGet.

Cheers,
Alana

Hi @forbzie22_0253 ,

Similar to the UI, packages are still returned in the API - they just have a flag set to indicate they are unlisted/deprecated. It's up to the client to determine what to do about that.

I don't believe the Find-Package cmdlet works with these properties; I think only Visual Studio will hide/warn about them.

Thanks,
Alana

hi @hammel_7023 ,

Thanks for letting us know, you are correct... this is indeed a regression from PG-2859.

What's happening is the upload stream is getting prematurely closed during the POM validation logic, which is what's causing this error to occur.

I've just patched it now via PG-2868, and it'll get in the next maintenance release.

Cheers,
Alana

Hi @MY_9476 ,

Thanks for the heads up! We will fix this via OT-514 in the next maintenance release.

As an FYI, this is the code that should have been run at the end of the database upgrade, to ensure that all procs and table-value params have appropriate permission:

DECLARE @SQL NVARCHAR(MAX) SET @SQL = ''
SELECT @SQL = @SQL + 'GRANT EXECUTE ON TYPE::' + QUOTENAME(name) + ' TO [OtterUser_Role] ' FROM sys.table_types 
SELECT @SQL = @SQL + 'GRANT EXECUTE ON ' + QUOTENAME(name) + ' TO [OtterUser_Role] ' FROM sys.procedures
EXEC sp_executesql @SQL

The script you ran works too :)

@steviecoaster great news, glad you got it all working

Hi @arose_5538 ,

Looks like this was indeed a regression in 2024.23 as a result of upgrading the JSON library we were using... I guess it's a lot more strict.

Of course, upack is also wrong, but for whatever reason it worked before. anyway it's an easy fix, and will be fixed in the next maintenance release (scheduled Feb 7) of ProGet via PG-2884.

In the meantime, you can just downgrade to 2024.22.

And I checked pgutil 2.1.0 will be released soon :)

Cheers,
Alana

Hi @jfullmer_7346 ,

I was able to reproduce this, and we will fix it in an upcoming maintenance release (PG-2920). This came from a regression in 2024.28, with some other NuGet feed changes.

Cheers,
Alana

Hi @daniel-pardo_5658 ,

Unfortunately I'm not able to reproduce the error; I think it has something to do with your upack.json file. Can you share that?

Thanks,
Alana

Thanks @daniel-pardo_5658 , I was able to reproduce it.

It seems to work when you have additional metadata fields. Anyway we'll get it fixed via PG-2935 in the next maintenance release. AS a work-around, you can just download the package, edit the upack.json, and reupload it.

Cheers,
Alana

Hi @mmaharjan_0067 ,

The pgutil assets list command is intended for interactive use and should not be parsed; it could change in future versions.

Instead, you can just call the endpoint directly, which will contain the details you're looking for:
https://docs.inedo.com/docs/proget/api/assets/folders/list

Cheers,
Alana

Hi @parthu-reddy ,

These are stored in the database and if you click "status" you can see the cached queries.

Does this metadata caching feature reduce the queries to fetch versions that you mentioned?

Yes, instead of going to NuGet.org, the database will be queried.

HOWEVER, this may actually reduce performance; NuGet.org is a static file system running on Azure Blob storage, and it might be quicker to download the query from Azure than to query your SQL Database.

You'd really need to expirement and see which is faster / more load.

Thanks,
Alana