Hi @tamir-dahan_7908 , Either you're making a typo somewhere, or there is something odd about your Docker/server configuration that is preventing a local network connection. I'm afraid I'm not a Docker expert, so I don't know what else to look for -- it could be specialized security configuration you have or a monitoring tool that's blocking things. If you have a Docker expert on your team, I would check with them to get some help. Ultimately, ProGet is just an ordinary .NET application making a connection on an ordinary SQL Server that's on the same local network (i.e. inedo-sql)... it's a super-common use case and just works out of the box. The most common issue is a typo (i.e. inedo-sql in one command and inedosql in another), but since this is such a common use case, if you search "Docker" and "A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible", you'll find a ton of results with lots of different things to try as well. If you're new to Docker, i would suggest installing with Inedo Hub - it's a lot easier to use. Cheers, Alana

Thanks for the feedback and the fix. Have a nice weekend.

Thanks for the quick fix. We didn't have that many packages assigned to the licenses in question, so the workaround of disconnecting all packages from a license and then deleting that license did the trick.

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! [image: 1719601545785-a8371438-7b61-4e65-b44f-002635d12fb5-image.png]

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: [image: 1718977649685-f146af02-09f1-4a91-839d-7f82d863c478-image.png] Have a good weekend.