Hi @r-riedinger_1931 ,

That error indicates that the database code (Stored Proc) didn't get updated, or is somehow out of sync with the installed version. Is it possible that you're pointing to an older database?

You may want to run the installer again, just to make sure.

Dean

@harald-somnes-hanssen_2204 unfortunately not; a feed index provides details about only the latest version of a package. You need a separate query to find details about all versions of a package, and then would need to do that query for each package in an index

Instead, it's better to just have a feed of approved packages that developers could use. This will let you also filter for other problems like quality.

We recently published some advice about, but it's for nuget feeds. https://blog.inedo.com/nuget/package-approval-workflow

It would work the same way for npm though

Hey @sylvain-martel_3976 !

Thanks for starting the discussion; I added it to our Other Feed Types to hopefully get some more attention.

I've been following WinGet for a little bit now, and if I'm being totally honest, I don't get it

My understanding of WinGet is that it's basically an index that simply points to installer files. In other words, there are no "WinGet packages" - the client simply goes to the index (a big ole yaml file from what I can gather), and downloads a MSIX installer. Is that what you've seen? Am I off here?

A lot of Chocolatey packages basically do this via a PowerShell script, and that's a big painpoint for folks who try to use it for anything other than some quick/basic workstation steup. Some do bundle their whole installer with Chocolatey, I've seen.

Can you tell me how / why you want to use WinGet? What are you currently doing without WinGet, and how will WinGet make it better?

Thanks,

Dean

@atripp @joshuagilman_1054

TIL that PowerShell can use internal CLR generic reference type names like that! But really, please don't do that...

• [System.Nullable``1[[System.Int32]]]
• [Nullable[int]]

... much easier to read

Thanks @nicolas-morissette_6285 -- we've received it, and I've attached to our internal dashboard. I can also see which domain/company you're with, based on the Email -- and it looks like your company purchased a license, thanks!

I'll escalate the priority internally, and from here we'll just try to reproduce/research this (might take a day or two)... but we'll update as soon as we learn more!

@JonathanEngstrom Otter v3 is still really early in the release cycle (closer to what folks used to call "beta" than "stable"), and we're getting the bugs worked out. We also fixed a bunch of bugs (unintended behavior) while testing v3, so it could be an unexpected change.

Please let us know specifically what you find so we can look to get things working. I'm not really sure what you mean by "Ensure Server $servername".

The only thing you should need to do is change PSEnsure -> PSEnsureScripts to get those scripts working, but the single-script will be a lot better once you get a hang of it. We plan to put a lot of work in documenting this new integration, and coming up with tons of examples to help folks verify the configuration and configure their servers.

The main real advantage to the new PSVerify/PSEnsure mechanics is that you can write a single PowerShell script to both verify and configure servers, and more easily create/modify/test/share those scripts outside of Otter.