@atripp If there's anything I can do to help with troubleshooting or debugging, I am happy to help.

@stevedennis Is there anything extra that needs to be done on my side to fix this with the recent fix. I'm still getting the error for this package. I've tried forcing the case to be the same but no dice thus far.

I have tried deleting the packages from my feeds completely, running the package re-index, and then pushing them again and the problem still persists.

So we internalize the chocolatey package WinSCP from the chocolatey community repository along with the matching version of the Powershell module of WinSCP from the PSGallery.

In both cases, proget 2025 is giving us a feed error on our powershell and chocolatey repos that this package has a "Noncanonical Name."

It gets indexed in the repo as winscp but the nuspec/psd1/psgetmoduleinfo.xml of the package has the id and (file names for nuspec and psd1) as WinSCP.

I am pushing the package via a drop path after some internal processes repackage the nupkg to our internalized format.
The WinSCP.nupkg we put in the drop path has the WinSCP case in the nupkg file name and the same for the nuspec within.

I've tried fully deleting all versions of the package in the gui but re-pushing it has it still coming back as winscp in the proget side list of the package and giving this unhealthy feed error.

I feel like I'm just missing something simple to fix this.

Thank you! I'll try to remember to report back after we update to that version.

I also attempted the same idea using the rest api

i.e.

sent this json in a post to the endpoint

{
  "userMetadata": {
    "version": {
      "includeInResponseHeader": "True",
      "value": "16.0.18925.20138"
    }
  },
  "userMetadataUpdateMode": "update",
  "type": "application/json"
}

Still get the same basic error message

Invoke-RestMethod: 42703: column "target" of relation "AssetItemMetadata" does not exist

Tried omitting the http response header boolean to no avail and tried creating a new key/value to no avail.

I'm trying out pgutil for adding some automation for the metadata in our assets (i.e. updating an asset file and metadata of its version)

I'm using the latest pgutil version 2.1.12 with the latest proget 2025.0.5 with the postgres backend.
We're using the integrated web server on http default port 8624 with iis as an https reverse proxy to that (in case it matters).
I have tried adding the pgutil source with both the https url and the http url.
I can always get the metadata of the object, i.e. (running in powershell, not as admin)

& C:\temp\pgutil.exe sources add --name=Default --url="https://proget.domain.local" --api-key="$($apiKey)"
pgutil assets metadata get --path="ExternalExes/Microsoft/odt.exe" --feed=resources
#returns:
Name: odt.exe
Size: 3799536
Type: https://proget.domain.local/endpoints/resources/content/ExternalExes/Microsoft/odt.exe
Created: 4/15/2025 3:22:11 PM
Modified: 4/15/2025 3:22:11 PM
Caching: Not set (inherit)

-- Hashes --
MD5: hash
SHA1: hash
SHA256: hash
SHA512: hash

-- Custom Metadata --
updateUrl: https://www.microsoft.com/en-us/download/confirmation.aspx?id=49117
version: 16.0.16731.20290

But then I try to update that (running in powershell)

& C:\temp\pgutil.exe assets metadata set custom --path="ExternalExes/Microsoft/odt.exe" --feed=resources --key="version" --value="16.0.18925.20138" --include-in-http-response
#returns
Setting version = 16.0.18925.20138 on ExternalExes/Microsoft/odt.exe...
Server responded with InternalServerError (500): 42703: column "target" of relation "AssetItemMetadata" does not exist

If I run it in .\ context in the same directory.

cd C:\temp
.\pgutil assets metadata set custom --path="ExternalExes/Microsoft/odt.exe" --feed=resources --key="version" --value="16.0.18925.20138" --include-in-http-response
#returns
Setting version = 16.0.18925.20138 on ExternalExes/Microsoft/odt.exe...
Server responded with InternalServerError (500): Exception while reading from stream

In this above example it did sit at the 'setting version' for a bit before erroring out.

I'm not seeing anything related in the logs available in the web gui, perhaps there's somewhere else I should look or maybe there's some simple syntax thing I'm missing?

Thanks,
-JJ

We recently upgraded to ProGet 2025, and even just now updated to 25.0.1 to make sure this wasn't already fixed.
For full context, we also migrated from sqlserver to postgres with the built-in wizard and have performed the integrity scans along with reindexes where it was recommended. We also moved to using IIS as the https proxy to where proget is now running on the integrated web server as was required for 2025. (Side note, kudos on all the documentation and guides that made that transition much easier than expected).

Onto the bug.

We have a version metadata entry on basically all of our asset repo items. Previously, editing this worked as expected, now we get this behavior:

We click version and we get:

Instead of seeing the current content. If we try to overwrite it like

we get

if we don't check the box same thing

We are able to add a new metadata with a different name and we can workaround this by deleting the old metadata entry and creating it anew.

I would also note that it no longer auto-updates/refreshes the page, have to manually refresh to see metadata changes, not that big of a deal but worth noting.

===What version does this affect?===
ProGet 2024.28, 2024.29 (Inedo Hub)

===How can we help? (in brief)===
When trying to browse files of a package it just errors out

===Please add any details that might help us help you.===
If we go to a powershell or chocolatey package in Proget 2024.28 or 2024.29 we can no longer view the contents of the nupkg file.
We use this feature as part of some imaging/provisioning automation to get a pkgs.txt file to know what programs are to be installed.
i.e. we might run invoke-restmethod on a url like this one:

https://domain.proget.url/package-files/download?feedName=Choco&group=&packageId=some-package&version=2503.1.6&path=tools%2Ffiles%2Fpkgs.txt&download=false

But right now that returns "ERROR: File not found" breaking our system provisioning. If we browse to the page in the web ui we see

We use this method so we don't have to store a list of packages in 2 places and can maintain it within a package. I imagine there are other use cases out there for browsing or getting the package contents.

@stevedennis said in Proget Service/Site Crashes with 500 Error:

shared memory provider error 40

Thank you for the insights, I was also thinking the sql server was the most significant thing. It is on the same server but it's also a virtual server, I don't think it's a hardware failure there.

There is another sql server running on the server for chocolatey central management, there may have been a conflict with a mismatched version dependency on that app for the dotnet-aspnetmodule-v2 where I need the 16.x version for CCM but I accidentally upgraded to the 17.x version.

At the moment the issues hasn't recurred since the day I reported it and I'm hoping having fixed that dependency has fixed the issue. I found some other things that mention local sql aliases needing to exist, I do use many dns aliases in the server's config so I might try making those as sql named pipe aliases to see if that makes any difference, though it seems a long shot.