If you're using Chocolatey at a version lower than 2.0.0 then there was only NuGet v2 support. Since 2.0.0 we've added support for NuGet v3. We also send chocolatey cli in the headers of the request, so you would be able to monitor the traffic and determin which traffic is originating from that tool. But as others mentioned, you wouldn't be able to determine much from the ProGet side.

Hi @steviecoaster , Sorry about giving the bad advice there -- I did not realize that the offline installer does not include the hub.exe program. It looks like the Offline Installer Creation Process must strip that from the offline installer we provide. As you discovered, the advice from before wouldn't really work. Without doing a deep dive in the code, I don't know how to make it work. This isn't a use case we designed for, and I'd hate to send you down a wild goose chase. How about just using our standard silent installation approach, which I shared before: # create working directories mkdir C:\InedoHub cd C:\InedoHub # download and extract file to working directory Invoke-WebRequest "https://proget.inedo.com/upack/Products/download/InedoReleases/DesktopHub?contentOnly=zip&latest" -OutFile C:\InedoHub\InedoHub.zip Expand-Archive -Path InedoHub.zip -DestinationPath C:\InedoHub # perform silent installation hub.exe install ProGet:5.2.3 --ConnectionString="Data Source=localhost; Integrated Security=True;" This will basically install the desired version and it's likely "good enough" for the time being. -- Dean

OK, Dean, thank you very much.

Hi @gdivis, thank you very much for your response! We are really looking forward to the finalized version :) Thanks, Caterina

Hi @jw, Thanks for sending this over. I created PG-2731 to track the fix. It should be out within the next two maintenance releases of ProGet. Thanks, Rich

Hi @atripp, thank you very much for clarifying this. We are not able to update to ProGet 2024 yet, so I will just resolve this issue manually for our projects. Thanks, Caterina

Hi @506576828_9736 , We don't have any templates or wizards for Vue project, but you can follow the guidance on Creating a Build Script from Scratch, which would involve the following steps: Get Source Compile Project (I think this involves running npm?) Record Dependencies [optional] Run Tests [optional] Capture Artifacts Once you capture the artifact, you can use or customize the Deploy Artifacts to File Share Script Template Please share your experience, as it'll help future users searching for this as well :) Thanks, Steve

Hi @parthu-reddy, This is usually an indication of an outside process accessing this file. To verify this, if you restart ProGet, access to that file will be restored. If it is still locked, then something external to ProGet is accessing it. The most likely culprit is an antivirus scanning that file when ProGet attempts to access it. Can you restart ProGet and see if there is still a file-locking issue? If the file is still locked, can you verify that you do not have an antivirus solution that is constantly scanning that file and locking it? Thanks, Dan

Ha, It was a goofy issue. I wasn't paying attention and had the Body defined as a string in my proxy function. This is working nicely now!

Hi @cstekelenburg_4169 , If you created a connector with the proper URL, username, and password, then you've set it up correctly. Please note, you will not be able to list or search remote packages in the ProGet UI. This is a limitation, since ADO is rudimentary and does not support listing/searching. Instead, you will need to use the NuGet API (Visual Studio, Nuget.exe) to pull packages. Once package has been pulled through ProGet, you will "see it" in the UI since it's been cached. I'm not trying to be pedantic with terminology, but please note it's not a "sync" -- it's more of a "proxy" or "pass through". When you make a request via the NuGet API, that API request is forwarded to your connector (I.e. Azure DevOps). -- Dean

Many thanks for that proposal, Steve! The warning label in conjunction with dumping of the package cache sounds like it is worth exploring. I shall discuss it with my security and governance collaborators :-)

Hi @scott-wright_8356 , Once connector caching is enabled, the error pattern is not used, so we only have this warning. I added a small change via PG-2726 which will add the connector name. This will appear in the next maintenance release (2024.9), scheduled for this week. Removing connector caching should reveal the connector name, so maybe that helps you identify it until then Thanks, Steve

Hi @sonali-prasad17_0018, Are you able to see the packages from the mirror in your Debian feed within ProGet? Also, do you get any errors when trying to update your source in Ubuntu? Thanks, Dan

@jw thanks for clarifying! The pipelines in ProGet are not really meant to track status. The main reason for the build stages is to control automatic archival, issue creation, and notifications. For example, your stable releases might stay in a "Released" stage indefinitely. We also had (in the preview feature) threre build statues: Active, Archived, Released. We don't use Released currently, but definitely something we may bring back. You don't want to delete a Released build, but you would probably want to delete an Archived build. Anyway, I'd check out the pgutil builds promote command - that way you can keep your "archival rules" in ProGet.

Thanks, Dean. This new build does indeed resolve the issue: Have a good weekend.

Hi @stevedennis, Seeing the PG-2716 solution included in the last release 24.0.8, we upgraded. In 2024.8 version the creation of new Debian feed works perfect, but the feedGroup property doesn't seem to do it. Could you double check if feedGroup is the right name, and if it's included on current version?

Great! I don't believe that there is any public reporting of VISX package vulnerabilities, so this is not data that would be available in ProGet either

Hi @daniels, This is technically possible, but it's not something that we support out-of-the-box I'm afraid. The closest way to accomplish something like this would be: Use the Otter API to create a server entry with the appropriate roles (similar to what you'd do in the UI) Install/run the agent on the computer which will connect to Otter Use the Otter API to trigger a job/ remediation Optionally, remove the server from Otter and Stop/uninstall the Agent So it's not easy from the user perspective. However. if Otter and this approach looks like it will work for you, then it's something we can definitely explore together as a user/customer, and build out a use case / case study / etc. That'd be best to start a conversation w/ someone in our customer / sales team on that. Otherwise, there really hasn't been enough demand for this particular use case, and it's hard enough to market Otter's other use cases, let alone develop build new ones ;) FYI - note that you can also run the Inedo Agent in outgoing mode: https://docs.inedo.com/docs/inedoagent-overview#communication-modes Thanks, Steve

Turns out the errors I encountered were entirely related to the "new" SQL Server driver that ProGet 2024 was using. Although this was in beta for well over a year, it was "only" in production for a few months by the time we incorporated it into ProGet. This driver issue impacts anyone who uses .NET on Linux. As I mention, I think it's pretty clear that Microsoft has effectively abandoned SQL Server. It's one thing to release something this low-quality and untested... and another to have it linger with issues like this in production for months. We will be moving to Postgres, which do not have these endemic problems. In the meantime, I have instituted the "one year rule" for Microsoft products - meaning, unless it's been shipped in their general release channel for a year, we will not even consider using it.