Version 3.4.2 works great, thanks!

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

@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.

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 @rhessinger Thanks, but I don't think we will need a pre-release. The remaining problem is basically a convenience issue (getting from the report to the package's info page with one click). Everything else seems to work as expected with the latest pgscan version.

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

@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

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

I can confirm that its working for us now. Thanks!

Hi @Evan_Mulawski_8840 , That particular bug may be resolved by running the patch script attached to this upcoming change: https://inedo.myjetbrains.com/youtrack/issue/PG-2484 As for retrying the migration; there will be a button on the ProGet root page if there is a failed/incomplete migration (/) that allows you to retry it. This will open to the /retry-migration URL, which I would recommend using instead of a database insert. Best, Dean

Correct; that, and the API key, are what get sent over.

@stevedennis Nice one, thanks for all your help

Hi @henderkes, No problem! Both these issues are expected to be fixed in this Friday's release of ProGet 2025.18. Thanks, Rich

I see, in that case, your network/server is not properly configured. This is not trivial to troubleshoot, and this is happening before the request hits our software. The most likely culprit is an invalid/missing SPN, and a domain administrator must add that. Here are some additional resources to follow: https://support.microsoft.com/en-us/kb/969060 http://www.sidesofmarch.com/index.php/archive/2011/11/04/troubleshooting-windows-authentication-in-iis/ http://serverfault.com/questions/341978/troubleshooting-windows-authentication-problems-no-challenge-in-iis-7-5 Search terms, "diagnosing windows authentication iis"

@daniel-lundqvist_1790 no problem.. docker is really confusing/silly... , glad we got it solved :)

Hi @inok_spb - that's correct, the proc is dropped/created each time ProGet is upgraded/installed.

@wechselberg-nisboerge_3629 great news, thanks! Well it'll be in the upcoming release (2025.13) in that case :)

I have tracked down the root cause of this issue. NuGet feeds (but not NuGet (quirks) feeds) in ProGet 5 generate a list of symbols, but never actually put them in the database. The fix is filed as PG-1195 and will be coming in the next version of ProGet 5. It includes a button in the feed management page to re-index all symbols in a feed, and packages affected by this bug have a message with a link to the feed management page in the place where the list of symbol files would normally be.

Neat graphic! Apple Passbook epeixlmfies wallet without nfc; Samsung Galaxy Note has nfc to beam files between phones, so it would represent the left. Google is working on the intersection of nfc and wallet, so it is nice Microsoft represents another entry into the nfc wallet category!

It could be that the versions were fixed up when a package cleanup ran - happens every day by default, but may not have been immediately after the upgrade. Thanks for letting us know about the zeros missing from that page; we'll add an issue for this to get fixed in the next release.