Yes, the privileges are scoped to a certain feed. You're right, As soon as i scope to "All Feeds", login works. That's great! I'm still abit confued about how to limit some people to only one feed. They should be able to Add, View, Download packages of one feed only (including uploading packages using the web ui). Other feeds should not be visible to them. How to achieve that without scoping my privilege to a certain feed. What I didis to create a new Role "HomePageViewer" Role with only the General_ViewHomePage Task. Then, I've created two assignments for my ProductDevelopers group: Principal:ProductDevelopers, Role:Package Consumer and Adder, Scope: MyFeed Principal:ProductDevelopers, Role:HomePageViewer, Scope: (System) Would that be a recommended way or did I think too complicated?

@Srinidhi-Patwari_0272 here is the api for healthcheck: https://docs.inedo.com/docs/proget-reference-api-health the url would be /health

This is unfortunately not trivial to debug, and will require understanding/learning how the symbol/source serving work (and the arcane tools to inspect said files), since it could be any number of things at this point, from your local pdb cache to improperly build pdb files. But take a look at some of the other Q&A posts with symbols tag, specifically this one which shows how to use pdbstr.exe to inspect. If you find out specifically what the issue was, please do share it.

Ah, that makes more sense! Yeah, Github is weird like that. I think if I provided the raw link then that right-click would have worked. Sorry for the confusion!

Hi @jw , Ah, I can see how that would happen; I logged this as PG-2425 and we'll try to get it fixed in the upcoming maintenance release. Steve

Hi @MF-60085, Thanks for the data! We've found that the root cause this time is due to some duplicate rows in the original table, which for some reason was not created with any uniqueness constraints. We'll get this fixed in a prerelease version within a day or two.

@Stephen-Schaff I think cc/ @rhessinger can correct me if I'm wrong, but you should be able to just rollback only the the InedoCore extension to 1.7, where we used the older version of the AD libraries. You can do this by downloading and manualy installing from here: https://proget.inedo.com/feeds/Extensions/inedox/InedoCore/1.7.12

That is great news! feel free to reach out if you have any other issues.

Thanks! Merged and released.

Hi @mikes_4196 , Per the discussion above... can you tell me a bit about "we" (i.e. the size/profile of your organization) and describe how you are using winget in your organization? And why did you use WinGet instead of Chocolatey? Per the discussion above, it does not look like a tool/ecosystem that is usable at scale. I get that it's built in to Windows, but I haven't seen a case study demonstrating a real deployment -- even within teams at Microsoft. The "central repository" is just a giant mess of files in a GitHub repository and can't reasonably be "proxied" via a connector like other feeds. They apparently have "private repositories", but there's no documentation/guidance on how to create/use private packages for end users, so I don't think many are doing this. But open to learning more. Cheers, Alex

I found this thread after experiencing a similar issue. I was seeing the "string is not a valid semantic version error" from Proget when npm would try to install scoped packages, but only when the npm install was automatically triggered inside Visual Studio by a change to the package.json. We already had the latest version of Proget with the change to the web.config and installs worked fine when running from command line. Problem turned out to be the fact that Visual Studio 2015 had installed it's own copy of the npm.cmd as an external web tool. This was an older version than the one I had installed globally, but the order of external web tool locations in Visual Studio had the path to the older version listed before my system path. Making system path take precedence solved the issue. Just thought I'd post this here in case anyone else with a similar issue stumbles across this thread like I did.

@apxltd At the moment we only have five I think. The adoption rate of it has been slow due to the SCA feature being very interesting but lacking the presentation of some valuable information, such as what this thread addresses. Once the adoption grows with increased information connectivity (builds with the associated packages for instance and this license component) we would likely have more than 300 or 400 build projects.

I would remove the "NuGet API Key" from your NuGet feed; that is a seperate thing from "ProGet API Keys", which makes it quite confusing. This is why it will be deprecated in v5. You don't need an API key; you can just publish using usename/[password.

Hi @shiv03_9800, We have just released a new version of Otter that includes a fix for the segmentation fault. You will need to make sure that .NET Framework 4.5.1 or greater is installed on the Windows server. But if you were able to run the Inedo Agent installer, then chances are you already have that installed. As for the Inedo Agent error, I talked with some colleagues and this is something we have seen on slower or congested networks when checking Inedo Agent has the components needed to communicate with Otter. Normally if you wait for the next server check to occur, the issue ends up resolving itself. There was another issue, however, that can affect PowerShell scripts when using the Docker version of Otter, OT-432. This was fixed in the latest release as well. Thanks, Rich

Hi @nicolas-morissette_6285, Always glad to help! Thanks for giving us an update and letting us know that this fixed your issue. Unfortunately, the package count is a side effect of ADO not implementing the search API. It does not give us the ability to get a package count. Thanks, Rich

hi @cshipley_6136, We chatted a bit about this as a team today. We believe that the application failed during initialization (i.e. the first web request after starting the service); when this happens, the error message will be returned until you restart the application (container/service). This is by design; there's no way to guess where or why the initialization failed, and if we "crash" the application (and trigger a restart), it can end up in a endless loop and make diagnosing really difficult. In this case, the error is network related (server name not found). That error can be transient when you have network problems, or permanent if it's a typo in the connection string. Since restarting the application (container) fixed it, then it was a transient network issue that happened during initialization. Hope this helps, Steve

Version 3.4.2 works great, thanks!

@Stephen-Schaff Very glad to hear! It makes absolutely no sense makes that Managed Pipeline Mode would have any impact on how these libraries behave... but there you have it. These libraries are ancient, and even Microsoft has no idea how they work anymore. Apparently Microsoft is working on shipping brand new libraries (no COM interop magic) in .NET6, which means by .NET8 they just might be usable, and then perhaps in another decade they won't require mysterious changes

Hello, this has finally been scheduled for 5.3.13, which is shipping tomorrow. It addresses only this specific test case, so please let us know if you're spotting other errors.

Hi @gravufo, Awesome! Just reply back here if it does start up again. Thanks, Rich