@lm FYI, our plan is to create a second URL for pushing symbol packages, and then essentially save the files pushed to that URL as .snupkg, next to the .nupkg files on disk. This URL will be wired to SymbolPackagePublish and documented.
So hopefully this will make a better user experience, and then also help w/ the hash bits as well.
@lm said in Uploading snupkg using NuGet client:
If I'm not completely wrong, all that is needed is a configuration option at the first feed "Use Feed x as symbol feed" and as soon as that is configured, the index.json of the first feed can return the correct SymbolPackagePublish resource and everything should just work.
You're correct -- that would probably work, but we thought a "single feed approach" would be much better from a user-experience standpoint. This way, there's just one feed to configure, and you push package files and/or symbol files to that feed using that default NuGet configuration. The files will be are stored on disk, right next to each other.
This is something we're planning for ProGet 2023, but can probably do as a preview feature in December or January.
@marc-ledent_9164 that page should redirect to the manual license activation page if it can't automatically update after a timeout (usually a few seconds) occurs
If it won't redirect, you can manually type in /administration/licensing/manual-activation and handle it that way.
Hi @g-koessler_0127 ,
This is a networking error, and it basically means that the remote server (http://nexus-proget.???) abruptly disconnected. There is no additional information provided by the remote server, so the networking stack (Windows/.NET) provides only this information.
This is almost always related to server-level security settings (HTTPS required, TLS settings on the ProGet server, certificate trust, etc.), but it also might be related to network-level settings like url restrictions, proxy servers, etc.
Ultimately I'm afraid it's not easy to troubleshoot - this is typically something that the network operations needs to help with, as they have tools and are familiar with restrictions placed on servers, and they can resolve them.
I'm hoping this at least points you in the right direction?
You can ignore this error; for whatever reason, the NuGet client unexpectedly terminated the connection, and the result was that ProGEt stopped writing bytes. Not really anything to worry about.
The diagnostic center isn't for proactive-monitoring, more for diagnostic purposes. So ulnless users are reporting a problem, you don't need to check it.
@rmusick_7875 generally speaking feed information is combined from chocolatey.org (and other connectors you configure), metadata stored in the database (the NuGet* tables), and cached/local package files on disk
@p-boeren_9744 sure thing!
Never noticed it before, but I just fixed as PG-2100 - and it'll go in 6.0.9 (
Feb 25)
@cronventis would you be able to get us the following?
/api/v1/pods)If so, we can provide a secure link to let you upload them to us. Note the namespace list might be multi-paged, which means you may need to use the continue argument; https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#list-all-namespaces-pod-v1-core
This would be the easiest for us to sift through, and you wouldn't have to run queries, etc.
If not, we'll think of something else :)
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
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.