@apxltd Thank you, problem fixed

@ashah_4271 can you share your OtterScript? and show specifically what you'd like to do? Happy to help if we can!

@Stephen-Schaff let us know! If that works, then we can just inject that in the package, and read it in on the history page, similar to this NuGet package: https://proget.inedo.com/feeds/NuGetLibraries/Inedo.ExecutionEngine/100.1.1/history

Hi @Stephen-Schaff , Thanks for the suggestion! So we had considered the "auto-generated one-time key" in our initial design, but decided against it for several reasons. This enables the less-secure "API Key Spreadsheet Antipattern" - basically people want to store keys they generate -- and since the software doesn't allow it, they go this route. It's the same problem with "change your password every 30 days" policies that create easier-to-guess passwords. This tends to create a lot of stale keys due to a fear to delete them. Administrators can "back-up" the API Keys if they can see them, and add-them back if cleaning up causes a problem. Allowing keys to be entered allows users to more easily migrate from one instance to another - just do a DNS change, and all old automations /old keys will work fine. API Keys are similar to passwords, but different; passwords are entered by a human to log-in, and in theory should only be "in that human's head" -- where as API Keys are always entered somewhere (usually in a script). In general, in ProGet, we recommend keeping API Key as limited as possible. This simplifies things for everyone. There's no practical security problems in allowing all users to publish packages to feed.... you should be using package promotion to test/verify packages anyway.

Hi @Stephen-Schaff , We already have "Personal API Keys" coming, so I think this will address those concerns. The User Impersonation is really only used by the "Feed API" Endpoints anyways, and the only "problematic" endpoints might be "Feed Management API" (they could delete feeds) or "Native API" (they could do anything). Otherwise, I think this would best be handled by training and documentation. Perhaps just a warning to put on the Create API Key page? We've learned the hard way that advanced settings like this are really hard to support -- everyone forgets they exist (including support team). steve

Hi @atripp thank you for your fast fix! We just installed the version 5.3.27-rc.15 and will monitor the behaviour the next days. Greetings, Michael

Hi @Michael-poutre_3915, It's strange indeed. I wonder if it's related to a locally cached version you have? I can't seem to find any documentation, but I believe PowerShell expects to only receive the latest version available unless a specific version is specified(This is based on the fact that if more than one package is found, it errors). Looking further into ProGet returning two results, we see that it is returning the latest non local version as well as the latest local version. I think if ProGet were configured to only return the latest version that that would work better Behind the scenes, PowerShell is calling the FindPackagesById() NuGet API method which is supposed to return all versions. You should see almost identical results to: https://www.powershellgallery.com/api/v2/FindPackagesById()?id='ExchangeOnlineManagement' https://proget.company.com/nuget/PowerShell/FindPackagesById()?id='ExchangeOnlineManagement' You'll notice the same with InvokeBuild as well; all versions are returned from the API, as expected. So this is why I think there's multiple repositories (a local one?) or caching, or some other thing with the client. I know you can install a module locally, in powershell, by copying the module file to a directory? Sorry I'm not really good with degubbing the PowerShellGet client, but hopefully we can figure it out.... Cheers, Alana

Hi @Stephen-Schaff , what you're doing should work, but this appears to be a bug due to the special-handling required for docker image promotion via API - so I've logged this as PG-1939 - we should get it fix in the next maintenance release.

thank you @rhessinger It is working fine. I have now to mix this version with the Scripting v1.10.2-CI.1 (bug for PSEnsure) Thank you guys for the fast correction

Thank you Alex bug is gone

@rhessinger You may also want to remove this message: [image: 1617901382998-2d876b1d-3959-4986-901b-86511845e0a0-image-resized.png] The big red banner is what got me looking into the license types in the first place. (I did not want my users to see the big red banner and I could see no way to suppress it except for getting a license assigned.)

OK. That aligns with what I was seeing. Thanks for explaining it to me!

@rhessinger said in Agent 49 - Otter 2 / Otter 3 ?: t you should be able to use the same agent install on more than one intance (Otter 3 and Otter 2.2) at the same time without issue. Basically, you can add that same agent to both Otter instances you have. Good news Thank you

Hi @ipluskal_1214 You're right, there haven't been any RPM changes... the error message is implying that ProGet is rejecting the data you're sending for some reason, "Unable to parse package header. The supplied package may be an invalid RPM file". It might be a .NET5 issue, just based on the version numbers you told me. Since ProGet v5.3.12, the inedo/proget image is hosted using the .NET Core runtime. Previously, it was hosted using the Mono runtime. The inedo/progetmono image is available to v5.3.19. Cheers, Alana

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

@joshuagilman_1054 this is currently planned for 5.3.27 as PG-1934 (April 17) - we'll let you know if plans change!

@afd-compras_2365 ProGet implements the NuGet Server API, so you can use ProGet as a private NuGet server; we did not design that API, we simply implement it Here is the same API call on NuGet gallery with a package that doesn't exist https://www.nuget.org/api/v2/FindPackagesById()?id='NotRealPackageFakeFAke'&semVerLevel=2.0.0 I'm not sure I understand the dependency question with nuget.exe though... but in a case like this, you can just put those packages in your feeds I believe? Then you won't get update issues

@brett-polivka sorry about that, there's always room to improve the testing, and you just got "unlucky" with a few edge cases that slipped through the cracks. But not to worry -- you can just downgrade the extension by following the manual installation instructions - the 1.9.0 of Azure will still use the old libraries - https://proget.inedo.com/feeds/Extensions/inedox/Azure/1.9.0