Hi @gravufo, The Inedo Hub lets you select which version you would like to install from a dropdown. You can also customize the feed that you would like to look for those packages. If that does not cover what you are looking for, technically you could generate offline installers for each version you would like to keep. Thanks, Rich

@atripp said in Proget 5.3 Docker Image: proget.inedo.com/productimages/inedo/proget:<version> Pulling that image is very slow! Can't you mirror the image to docker hub please?

Thanks for the fast resolution

Thanks for the report , very simple code typo and now it'll be fixed in BM-3611 in the next maintence release

@atripp . Thank you very much. Especially for pointing to right docs.

Hi @antony-booth_1029 , Looks like we had an issue in how the javascript resource is loading for this modal. I have fixed this and it will be released in the next version of BuildMaster 6.2.14 which is due out at the end of this week. Thanks, Rich

Hello, great question. .indeox deployment is no longer supported, so I updated the documentation as follows Direct Deployment {#zip-file} An extension can be directly deployed to an Inedo product's extension root as a simple universal package. To do for an extension named MyExample, first create a manifest file called upack.json with the following contents: { "name": "MyExample", "version": "1.0.1" } Then, create a zip file called MyExample.zip with the compiled output in a package folder, and the upack.json at the root, like this: /package/ /MyExample.dll /SomeLibrary.dll /upack.json Rename the the zip file to MyExample.upack, and copy the .upack file into the Product extensions directory. By default, this will usually be in C:\ProgramData\«product-name»\Extensions, but you can verify the exact location by going to the Admin->All Settings page and looking for the ExtensionsPath value. Finally, restart the product services (and application pool if hosting in IIS).

Hi @luminiscence_6236 , I'm glad to hear you figured out the issue. I'm going to add an internal ticket to add better error handling around docker connectors. Thanks, Rich

hi Simon, This records are maintained via Package Usage Scanning, which is something that routinely scans external resources for packages, and updates the status when a package is or isn't installed. It's a little different from deployment records, in that deployment records are historic data and package usage is current data. While you could write your own PackageContainerScanner by using the Inedo.SDK, Otter can collect the packages that are actually installed on various servers; the Otter-usage scanner (buitl in) simply queries to Otter about the status of those scans.

A server cluster can have up to 5 nodes; so in the case of a HA cluster, then it'd be the $10K for servers (But you could have up to 5).

@gdivis

We've clarified the instructions for mounting the packages volume. In short, both formats will persist packages beyond the container's lifetime, but if you already have packages stored somewhere, you'll need to mount that directory (as you discovered) instead of using the "proget-packages" Docker volume.

Hello; We are aware of the vulnerabilities. Our usage of this library is minimal, and we do not use it in a manner that would impact product security (i.e. "passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others). So please consider this a "false positive". Upgrading the library to 3.5.0 would add no value to ProGet users, but it would provide significant risk of UI regressions and risk of introducing unknown security vulnerabilities, that haven't yet been reported.

@atripp --registry is just the global arg for swapping out your registry on a per-command basis (instead of in a config file). But! i just realised what was wrong, apologies it's all on me. I still had the old url hardcoded in the publishConfig.registry key in the test modules package.json. i didn't realise that would make npm completely ignore the --registry arg, and blindly try and publish to the old registry address! which was why npm install etc were all working totally fine

@atripp said in ProGet Slow with Active Directory (New) directory: se we can make a few optimizations to recursive searching, but you shouldn't bee seing 5-second page load times in We also get incredible slow performance with "Search Recursively" enabled, our AD directory is quite large (tens of thousands of users), and having read this post, we have improved performance now as a result of disabling "search recursively". Ours was taking around 30 seconds to load a page before, it was pretty painful! I've developed an alternative to AD which suits our requirements and that is to use Atlassian Crowd - I'd be happy to share the source for that when it's finalised. (I also have a support ticket to log with AD regarding "A referral was returned from the server", but I'll post that through the proper support channels.)

@atripp Thanks for the answer. We will update and try again.

Hi, It looks like this is indeed an issue with the Content-Length header not being set properly when ProGet is running as a Linux container. I've logged this as PG-1740.

Hi @patchlings, No problem! We are still investigating some workarounds, but we don't have anything specific yet. We don't currently have a timeline for the .NET 5 switch. We have attempted a .NET Core transition in early 2019, but we ran into too many instability issues and scrapped it. We will wait for .NET 5 to be officially released (Microsoft says November 2020) before we attempt the switch, but it will all come down to the stability of ProGet on .NET 5. Thanks, Rich

Hi, I've solved the problem now. We have reverse proxy and the max request body size value was not set. I think that resulted in the proxy only allowing very small sized packages through, causing the slow network.

Great, thanks! What specific information is missing from the "landing" page? Even the "old" package page has many tabs, so not everything is displayed.