Thanks! Everything looks like it working fine.

Thanks for the update @Stephen-Schaff -- And just to add to this, you should see "Note that you can use the following alternative tags to refer to this image:..." on the browse image page.

@NanciCalo, Thank you for your prompt help! We have contacted our purchasing department to get a rush order on the new license. ("Rush" means that I hope to have it in a week or so.) I was able to put in a trial license and everything seems to be working fine. It says it is good until the 27 of June, which should be more than enough time to get a new license purchased and installed. Thank you again for keeping us running!

Hi @Ashley_8010 In nearly all of our external retail websites, there are tonnes of connections to third party websites which inevitably drive up the loading times for our customers. Some loading times can be upwards of 10+ seconds (depending on huge sneaker drops or major releases) It sounds like what might need is a sort of web bundler/packager (perhaps like webpack)? And then a Content Delivery Network on top of that, that can cache and serve static content faster than your server? We use Cloudflare ourselves. ProGet does allow you to access individual files within a package (see the files tab on InedoLib for example), and download those files with a URL like this. However, this feature was not designed to be a front-end web server, and I wouldn't recommend using it as such. Cheers, Alana

Hi @joel_6345 , Can I trouble you to read the latest version of the documentation? https://docs.inedo.com/docs/proget-feeds-nuget-symbol-and-source-server Actually I just rewrote it, so I'm really hoping that this can clarify your question .. and that it would have made it easier in the first place :) thank you

That does indeed have the info. Thank you!

Hi @atripp Unfortunately the setApiKey is not supported by the dotnet CLI. Dotnet tooling regarding package management is not ideal when it comes to nuget and dotnet nuget. Thanks for your replies.

Hi @kichikawa_2913, Sorry, this is actually expected. When we release our products, they include the extensions that were released at the time of the product release. In this case, I released this version of InedoCore after we did the product release. If you look at our documentation for upgrading your docker image, the command includes --volumes-from=proget-old. This will auto migrate the previous volumes created from the previous version of ProGet and that will keep the updated extension (as long as the previous extensions is newer than the included extension version). Also, in Administration -> Advanced Settings, you can change Extensions.ExtensionsPath to a mapped path and that will also do the same thing (if the version in this directory is newer than the included) and give you easier access to the extension files. Thanks, Rich

Looks like that was our mistake, and we missed that line in the spec. This has now been logged as PG-1964, and it will be fixed in ProGet 5.3.30, scheduled for release on May 28. Thanks for pointing it out, and sorry for the inconvenience!

@saml_4392 said in ProGet hosting in k8s or VM?: Btw, how do you measure the performance? Do you test it with a reverse proxy or use dotnet core directly? In this case, it's mostly about what happens when the servers get overwhelmed with traffic - and it's largely anecdotal. So it could just as well be related to other factors, like other programs running on the servers running the Linux clusters, or SQL Client for Linux not performing as well, or who knows. With Windows, people tend to set up dedicated or virtual servers with strict hardware provisioning.

@joshy-mathew_7277 what type of package is this? HTTP is not a great protocol for pushing really large files like that, and things like IIS and Middleware breakdown with huge requests. ProGet doesn't have any limits per se, but the 503 error means that something between ProGet and your browser is killing the request. It's usually IIS. Most of the client tools (NuGet, etc.) do not support "chunked" file uploads (Docker does), which is why we recommend using drop folder for these large files.

Hi @sejhemming_5842 Is there an accepted Code of Practice for managing prerelease stuff? Yes, the general rules to follow are these: Packages are immutable; do not delete/republish packages as part of your normal workflow Use Prerelease Packages & Repackaging to take tested/validated prerelease packages to stable packages Use Package Promotion to move packages across feeds Use Retention Rules to automatically cleanup unused prerelease packages Do people publish prerelease stuff to a different feed and only post the released stuff to the more public feed? Or is it just expected that once the release is out that the prerelease builds are simply removed from the feed? Yes to both On our ProGet Instance, we use both patterns. Extensions (plugins) have two feeds: Extensions (Stable) and PrereleaseExtensions; the reason is that we use CI (build automation), and publish a new package on every commit, and these could be really unstable - we don't want anyone using a prerelease extension unless we explicitly point them to it Our NuGet libraries have one feed (NuGetLibraries) that has both prerelease and release packages; these are not intended for anyone other than Inedo Engineers, and we have policies, practices, and training in place to make prerelease packages are shipped appropriately My advice for deciding which pattern to follow would be looking at the consumers of your feeds/packages (i.e. who uses your packages vs who publishes your packages). Using a single feed that has release and prerelease packages requires more training for developers. If one of your developers accidently uses a prerelease package and commits that, then it's going to cause problems. Even if you catch it before production, it will waste time and resources.

@gdivis Thanks for the resolution

Hi @atripp and @rhessinger I gave up with the installer and decided to use the docker image. It works fine. I suggest you test the installer in the exact scenario I described above. It might cause trouble for other users. Thank you for your replies.

Add my plus-1 to sorting or searching or filtering by groupname in the UI. As best I can remember, groupname is required by the upload process; at least, i remember it being required by the Jenkins plugin. Maybe i'm wrong/misremembering. But it does make sense for our use case to be able to divide feednames by groups. So it'd be great to have that functionality in the UI.

@arozanski_1087 no problem! And by the way, the pgscan tool is open source, so if you see opportunities to improve it, or want to devleop something on your own, please don't hesitate to use the sources - https://github.com/Inedo/pgscan

Hi @philippe-camelio_3885, I have just built a new CI version of the [Scripting Extension 1.10.3-CI.3] (https://proget.inedo.com/feeds/PrereleaseExtensions/inedox/Scripting/1.10.3-CI.3). This version includes the Minimum Version on Ensure PS Module and adds a new Ensure-PsRepository operation. Please take a look and let me know if you have any issues. Thanks, Rich

@atripp Oups Sorry about that. I made other tests since I created the thread. The data I send you are not correct I will wait for the 3.0.6 to make a clean test case and update the thread.

It cleared up on its own. Thank you very much for your help, Marko