ProGet v2025.5
In the Retention rules, if we enter a size of feed greater than 2097000mb, and then save, then we end up with a negative number displayed for the quota. I was aiming for 3TB - but i can foresee that at some point we might want to go much higher in the not too distance future.
The reason it's desirable is that although it's easy to get AD groups added, they are administered by a central department within the company, so each time we wish to add or remove somebody from a ProGet group, the change has to be requested, and this takes some time.
Other products we use such as TeamCity and Jira allow this. Also the system we used before ProGet allowed it :-)
It would be useful to allow Active Directory users to be added to built in groups, so that group management can be controlled locally within ProGet.
Proget 2025.3
With universal packages - in the usage instructions, the 'group name' gets repeated twice in the usage instructions, in all 3 tabs, upack client, cURL and PowerShell:
@phopkins_6694 - I've successfully used "delete all versions" in 2025.3 - but on an NPM feed rather than Choco. However I pressed the "Delete Package" button from your second screenshot rather than the "Delete Specific Version..." button that you have highlighted.
Hi @atripp,
One of the uses for upacks for us, is for storing binary images for things that are subsequently included into other CI builds. These are usually things are are not updated particularly frequently, and are not built by our CI system, for example an FPGA image, or perhaps some binary image provided to us by a component manufacturer.
So the process to update these packages is generally manual - we could use pgutil, but the UI seemed like a really nice feature. It's great for creating the first version of a package, but it just seems a bit awkward when adding a new version of an existing package, as you have to carefully re-enter the group and package name to match the existing package. So having a shortcut on the package page to add a new version of a package with the group and package name pre-filled would be really helpful.
ProGet 2025.3
On the Tasks / Permissions screen, sometimes (probably when there are an even number of rows in 'scope'). Due to the alternating shading, it's not possible to see where the divide should be between different task names:
A user with only 'Publish Packages' permission can't clear at least some ProTips. When they click the close icon on the ProTip, the error is displayed: "<username> is not permitted to perform the Admin_ManageFeed task for the current scope."
ProGet v2025.3 - Basic Edition
Since upgrading from 2024.36 to 2025.3 the user interface to allow universal packages to be created is no longer available for users with "Publish Package" permissions/task. Note this the default 'publish package' task - completely unmodified. Seems to apply to all feed types - but haven't extensively tested it.
2024.36:
2025.3:
I've made a bit of progress on this problem. I've now moved up to ProGet 2025.3 - and the image now does have lots of locales available (maybe they were there before, but I hadn't discovered how to enable them).
To enable specific locales it is necessary, it seems, to uncomment the appropriate lines in /etc/locale.gen, and run the locale-gen command.
It's then possible to set LC_TIME to this locale, and now when you send the date command it is formatted in the selected locale.
To achieve this i've added the following to my docker-compose.yml:
entrypoint: sh -c "sed -i 's/# en_DK/en_DK/' /etc/locale.gen && locale-gen && /entrypoint.sh"
environment:
LC_TIME: "en_DK.utf8"
However - having done all that - The ProGet UI doesn't actually format the dates in the system locale of the container.
It would be handy to have a way to access the UI to create a universal package via the package's page. The package group and package name could therefore be pre-filled, to avoid having to cut and paste it, or for a mistake to be made in the name of the group or package. (same workflow as using the create package UI from the feed page)
I've just used "pgutil packages repackage" to change the versions on all my erroneously versioned packages from w.x.y.z to w.x.y-ci.z.
I was expecting only to see the newly versioned packages, but in fact i now have both versions listed - is this the intended / expected behaviour?
Also, i'm not seeing anything in the history tab to show that the package has been repackaged. But I can see the 'repackageHisory' in the upack.json.
ProGet version 2024.36 (build 5) - Trial license (Basic Edition Features)
@stevedennis - I'm migrating items from another system, and we do use 4-part version numbers (where the 4th is the build number). But we don't want it to ignore the build number part. Combining parts 3 and 4 isn't very pretty, and won't give a very good first impression of ProGet to my users if I say that that's not supported.
I'll look into going do the -ci.xxx route - I assume it will order them alphabetically rather than numerically though - so i guess i need to pad them with 0's to the maximum likely width.
I would like to change the date display format within the ProGet UI - either to British (dd/mm/yyyy) or better still ISO-8601 (yyyy-mm-dd).
I've found from an earlier thread that ProGet uses the systems locale settings - but we are using ProGet running on Docker - and there doesn't appear to be any locales available within the ProGet docker container. I've tried setting the environment variable LC_TIME, but it doesn't work - probably due to the locale i've specified not existing in the container.
Any ideas how to resolve this?
It would be really useful to have a way to get the URL of a file within a universal package. Could a extra option be added to the context menu in the file view to copy the URL? It's possible to grab it via the browser DevTools, when you press the Download menu entry, but it's not very convenient.
ProGet Free Edition - v2024.36 (build 5)
I'm having trouble using build numbers in the version of Universal Packages in Proget.
The Symantic Version spec https://semver.org/ suggests I should be able to add "+" <build> to a version number. However if i create packages with build numbers, they seem to overwrite previous packages of the same version (but different build number) - and the build number doesn't show up anywhere in the UI.
Alternatively i've tried creating packages with the version format w.x.y.z - which is not permitted through the create package UI, but PGUtil allows. This mostly works, except that the sorting doesn't work correctly when you list the packages (it works correctly for x.y.z style versions).
Even though this version convention doesn't meet the semantic version spec - it would be good it it continued to work, as i've now migrated all my data using this format, as the +<build> didn't work.
Yes - they are "self-connectors". We've now bought an externally signed certificate, as it seemed like the simpler option (the in house cert option was causing other issues too). However that hasn't resolved the issue with the self-connectors.
However, I've just edited those connectors manually to use http rather than https, and that has resolved the issue. But It's not really an ideal solution.
So it looks like from inside the docker container it's still not "trusting" the externally signed certificate.
@stevedennis - Thanks - switching to a trial of Basic Edition resolves the issue. However i'm fairly sure you don't get a UI warning when you setup a feed-level permission on the Free Edition.
Also you can add personal API keys in the free edition without warning - in fact on the API keys page, you even get a tick saying 'personal APU keys are enabled'
It's not the feed that connects directly to npmjs.org that has these errors, it's the feed that aggregates the other two - so it's almost as if it's having a problem with it's own feeds?
ProGet is running under docker, and I don't think your docker container has curl - so that makes it tricky.
Proget 2024.36 (build 5) - Free edition
I've created 3 NPM feeds:
first one connects to npsjs.org in order to cache packages
seconds one has no connectors, and is for local packages
third one aggregates the other two
If you view the feed page for the aggregate feed - you see error messages for both the connectors:
The ProGet server has a valid SSL certificate - Although, if it's relevant, it is issued by our own internal Certificate Authority.
There are no message showing in the Diagnostic Centre.
I'm using the built-in/unmodified publish packages task. Also note, I'm using the free edition.
I've tried 'specific users...' and 'specific groups...' - but the same happen with either.
In the "tasks" box i'm only adding the 'publish packages' task.
I've tried the specific feed i want to allow publishing to, and that fails.
I've tried <NPM> which is the feed group - which also fails.
However choosing <all feeds and groups> allows successful publishing.
The client is using the API key for auth I believe.
When assigning tasks/permissions to publish NPM packages in ProGet, it seems to be necessary to give 'publish packages' permission for 'all feeds'. Specifying one specific feed, or even the NPM group is not sufficient, and results in the npm publish failing.
ProGet version 2024.36 (build 5)
I've now found a cleaner way of adding this entry to the host file...
If using docker run, add the argument:
--add-host=<host_server_name>=127.0.0.1
if using a docker compose file, add an entry:
extra_hosts:
- "<host_server_name>: 127.0.0.1"
To be fair, i think i might have a bigger problem - i may have corrupted my database somehow.
If I go to the Feeds, and then click 'connectors', i get I get a 500 error "Invalid Feed type".
An error occurred in the web application: Invalid feed type.
URL: http://<servername>/connectors
Referrer: http://<servername>/feeds
User: <username>
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
Stack trace: at Inedo.ProGet.Feeds.Connector.GetConnector(Connectors dbConnector) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E523495\Src\ProGetCoreEx\Feeds\Connector.cs:line 234
at Inedo.ProGet.WebApplication.Pages.Connectors.ListConnectorsPage.CreateChildControls() in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E523495\Src\ProGet.WebApplication\Pages\Connectors\ListConnectorsPage.cs:line 38
at Inedo.ProGet.WebApplication.Pages.ProGetSimplePage.InitializeAsync() in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E523495\Src\ProGet.WebApplication\Pages\ProGetSimplePage.cs:line 56
at Inedo.Web.PageFree.SimplePageBase.ExecutePageLifeCycleAsync()
at Inedo.Web.PageFree.SimplePageBase.ProcessRequestAsync(AhHttpContext context)
at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)
::Web Error on 02/07/2025 15:52:30::
I've tried deleting all the Cargo feeds to try and fix the issue, and then re-created them, but that's not helped.
ProGet Version 2024.25 (build 11)
On our Cargo aggregated feed the formatting of the description on the webpage for the feed appears to be incorrect:
However looking at the same package on the feed that caches from the internet it works correctly:
Hi @gdivis
Ah yes, i was on 2024.0.25 build 10 (interesting to note that 24.0.25-ci10 shows up on https://proget.inedo.com/containers/repositories/ProductImages/inedo/proget/overview in the 'recent images' section of the overview tab, but 24.0.25-ci11 doesn't (but it is listed in 'all tags')
I've now switched over to 2024.0.25-ci11 but still have the same problem.
An error occurred processing a GET request to http://<servername>/cargo/cargo-aggregate/bi/tf/bitflags: The remote server returned an error: (404) Not Found.
System.Net.WebException: The remote server returned an error: (404) Not Found.
at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)
--- End of stack trace from previous location ---
at System.Net.WebRequest.GetResponseAsync()
at Inedo.ProGet.GlobalExtensions.GetResponseAsync(HttpWebRequest request, CancellationToken cancellationToken) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E523661\Src\ProGetCoreEx\GlobalExtensions.cs:line 36
at Inedo.ProGet.Feeds.Connector.GetDirectResponseAsync(String url, CancellationToken cancellationToken) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E523661\Src\ProGetCoreEx\Feeds\Connector.cs:line 525
at Inedo.ProGet.Feeds.Cargo.CargoConnector.GetPackagesAsync(PackageNameId name, String version, CancellationToken cancellationToken)+MoveNext() in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E523661\Src\ProGetCoreEx\Feeds\Cargo\CargoConnector.cs:line 96
at Inedo.ProGet.Feeds.Cargo.CargoConnector.GetPackagesAsync(PackageNameId name, String version, CancellationToken cancellationToken)+System.Threading.Tasks.Sources.IValueTaskSource<System.Boolean>.GetResult()
at Inedo.ProGet.Feeds.StandardCanonicalPackageFeed`5.AggregateWithConnectors(IEnumerable`1 localPackages, Func`3 getConnectorPackages, CancellationToken cancellationToken)+MoveNext() in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E523661\Src\ProGetCoreEx\Feeds\StandardCanonicalPackageFeed.cs:line 395
at Inedo.ProGet.Feeds.StandardCanonicalPackageFeed`5.AggregateWithConnectors(IEnumerable`1 localPackages, Func`3 getConnectorPackages, CancellationToken cancellationToken)+MoveNext() in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E523661\Src\ProGetCoreEx\Feeds\StandardCanonicalPackageFeed.cs:line 395
at Inedo.ProGet.Feeds.StandardCanonicalPackageFeed`5.AggregateWithConnectors(IEnumerable`1 localPackages, Func`3 getConnectorPackages, CancellationToken cancellationToken)+System.Threading.Tasks.Sources.IValueTaskSource<System.Boolean>.GetResult()
at System.Collections.Generic.AsyncEnumerableHelpers.ToArrayWithLength[T](IAsyncEnumerable`1 source, CancellationToken cancellationToken) in /_/Ix.NET/Source/System.Linq.Async/System/Linq/AsyncEnumerableHelpers.cs:line 49
at System.Collections.Generic.AsyncEnumerableHelpers.ToArrayWithLength[T](IAsyncEnumerable`1 source, CancellationToken cancellationToken) in /_/Ix.NET/Source/System.Linq.Async/System/Linq/AsyncEnumerableHelpers.cs:line 41
at System.Linq.OrderedAsyncEnumerable`1.ToListAsync(CancellationToken cancellationToken)
at Inedo.ProGet.WebApplication.FeedEndpoints.Cargo.CargoIndexHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, CargoFeed feed, String relativeUrl) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E523661\Src\ProGet.WebApplication\FeedEndpoints\Cargo\CargoIndexHandler.cs:line 68
at Inedo.ProGet.WebApplication.FeedEndpoints.Cargo.CargoFeedHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, CargoFeed feed, String relativeUrl) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E523661\Src\ProGet.WebApplication\FeedEndpoints\Cargo\CargoFeedHandler.cs:line 107
at Inedo.ProGet.WebApplication.FeedEndpoints.CanonicalFeedHandler`1.Inedo.Web.IHttpAsyncHandler.ProcessRequestAsync(AhHttpContext context) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E523661\Src\ProGet.WebApplication\FeedEndpoints\CanonicalFeedHandler.cs:line 85
::Web Error on 02/07/2025 10:07:23::
ProGet Version 2024.25
I've found exactly the same problem exists with Rust Crates... You can access all the packages correctly in the cargo-external feed.
However if you create a feed (cargo-aggregate) to aggregate cargo-external and cargo-internal then you can see the packages listed on the feed page for cargo-aggregate, but if you try to click through to any of the packages, or you try to download from this feed via cargo, then you get a 500 error.
(Note: caching is switched off on the aggregate feed)
Proget version : 2024.25
Steps to reproduce:
Create a new rust project 'cargo new <projectname>'
edit cargo.toml - in the dependencies section add one of the following:
syn = "2.8.0"
log = "0.4.25"
num = "0.4.3"
then run 'cargo build' - cargo fails to download any of these packages.
however trying packages:
libc = "0.2.169"
rand = "0.9.0"
these work perfectly.
@gdivis - Brilliant, I've just switched over to 2024.25, and they both are now working perfectly.
PyPi still isn't showing any packages in on the webpage for the feed - but that's not essential.
Thanks for the impressive swift resolution.
For the PyPi feed:
An error occurred processing a GET request to http://servername/pypi/pypi-aggregate/download/package_name/0.0.10/package_name-0.0.10-py3-none-any.whl: Specified method is not supported.
System.NotSupportedException: Specified method is not supported.
at System.Net.Http.HttpBaseStream.get_Length()
at Inedo.IO.DisposingStream.get_Length()
at Inedo.Web.AhHttpResponse.TransmitStreamAsync(Stream stream, String fileName, String contentType, Nullable`1 contentLength)
at Inedo.ProGet.WebApplication.FeedEndpoints.Pypi.PackageDownloadHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, PypiFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.Pypi.PypiHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, PypiFeed feed, String relativeUrl) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E520165\Src\ProGet.WebApplication\FeedEndpoints\Pypi\PypiHandler.cs:line 34
at Inedo.ProGet.WebApplication.FeedEndpoints.FeedEndpointHandler.FeedRequestHandler.ProcessRequestAsync(AhHttpContext context) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E520165\Src\ProGet.WebApplication\FeedEndpoints\FeedEndpointHandler.cs:line 191
::Web Error on 01/24/2025 08:48:40::
And for the NPM Feed:
An error occurred processing a GET request to http://servername/npm/npm-aggregate/@company_name/package_name/-/package_name-1.0.28.tgz: Specified method is not supported.
System.NotSupportedException: Specified method is not supported.
at System.Net.Http.HttpBaseStream.get_Length()
at Inedo.IO.DisposingStream.get_Length()
at Inedo.Web.AhHttpResponse.TransmitStreamAsync(Stream stream, String fileName, String contentType, Nullable`1 contentLength)
at Inedo.ProGet.WebApplication.FeedEndpoints.Npm.NpmPackageDownloadHandler.TryProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, NpmFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.Npm.NpmHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, NpmFeed feed, String relativeUrl) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E520165\Src\ProGet.WebApplication\FeedEndpoints\Npm\NpmHandler.cs:line 111
at Inedo.ProGet.WebApplication.FeedEndpoints.FeedEndpointHandler.FeedRequestHandler.ProcessRequestAsync(AhHttpContext context) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E520165\Src\ProGet.WebApplication\FeedEndpoints\FeedEndpointHandler.cs:line 191
::Web Error on 01/24/2025 09:20:33::
In both cases if I change the feed name in the URL to pypi-internal or npn-internal as applicable, then those files are downloaded correctly.
It's also worth noting that in the web user interface neither the pypi-aggregate nor the npm-aggregate feeds show any packages on the feed's page.
The URLs that the connectors are configured to are of the form:
http://servername/pypi/pypi-internal/simple
and
http://servername/npm/npm-internal/
I've now tested aggregating 2 feeds for NuGet, Conan, NPM and PyPi with mixed results:
NuGet aggregate feed works absolutely perfectly.
Conan aggregate feed essentially works perfectly - however when you fetch a new Conan package from the aggregate feed, it doesn't show up in the package list in the web-ui of the "conan-external" feed which is set to cache. (note the aggregate feed is not set to cache). However it looks like any dependencies of that package are showing up as fetched.
PyPi aggregate feed doesn't work at all (although both the internal and external feeds are working separately):
> pip install yolk3k
Looking in indexes: http://<servername>/pypi/pypi-aggregate/simple
Collecting yolk3k
ERROR: Could not install packages due to an OSError: HTTPConnectionPool(host='<servername>', port=80): Max retries exceeded with url: /pypi/pypi-aggregate/download/yolk3k/0.9/yolk3k-0.9.tar.gz (Caused by ResponseError('too many 500 error responses'))
NPM aggregate feed doesn't work at all either (although both the internal and external feeds are working separately):
> npm i zlib
(very long pause)
npm error code E500
npm error 500 Internal Server Error - GET http://<servername>/npm/npm-aggregate/zlib/-/zlib-1.0.5.tgz - NotSupportedException
npm error A complete log of this run can be found in: /home/???/.npm/_logs/2025-01-23T14_41_20_729Z-debug-0.log
I've created a Conan feed in ProGet (Free edition - 2024.24) to connect to conan.io, but it doesn't appear to fully work.
i've added a new remote 'proget' to conan on the client as per:
https://docs.inedo.com/docs/proget/feeds/conan
If i do a conan install using a conanfile, then all is working perfectly.
However if I execute a conan download command i get the following result:
> conan download -r proget zlib/1.3.1:*
ERROR: b'expected files after revision'. [Remote: proget]
The same command works correctly on our other (not ProGet) conan server
Tested using Conan client version 2.9.2 and 2.11.0
Many thanks, i've now resolved the violation issue. It was very helpful to be able to clear the violation list to be able to see what was going on. Will the violation banner disappear on it's own in due course?
The solution was to add an entry in /etc/hosts in the docker container - I hadn't got it quite right previously. To do this:
docker exec -it proget bash
printf "127.0.0.1 <host_server_name>\n" >> /etc/hosts
I've found other forum posts that suggests unsetting Web.BaseURL or creating an entry in /etc/hosts which maps the machine name to 127.0.0.1 - but neither of these seem to help.
Thanks for the explanation - i think i've managed to resolve the connection refused issue, but that hasn't resolved the problem, and I now also have a error reporting license violations.
I had originally mapped port 80 on the docker container to port 8080, as my docker was running rootless, and it wouldn't bind to ports below 1024. However confusingly when tring to connect to the host machine on port 8080 from inside the container it resulted in connection refused... but port 80 seemed to be accepting connections (even though there was no service running on port 80 on the host).
So switching back to port 80 seemed like the easiest solution - which has made the errors reporting connection refused disappear, however I now have a red banner reporting license violations, and the aggregate feed still doesn't work. (maybe the violation detection blocks the feeds in question?).
Does the license violation work when using docker containers? In that does it understand that the container running ProGet isn't the same machine as the machine apparently providing the feeds (which is the docker host)
Alternatively have I caused this problem by changing the port number which makes it look like a different instance, and there is still a reference to port 8080 somewhere. (i've updated Advanced Settings -> Web.BaseURL)
I'm currently evaluating ProGet using the Free Edition.
I've setup a feed 'npm-internal' with no connectors to act as storage for internal packages
I've also setup a feed 'npm-external' to proxy and cache registry.npmjs.org
I would like to be able to aggregate these into 1 feed, which the documentation suggests is possible in the free edition.
You are allowed to connect to 'other feeds in the same instance'
I appreciate it's possible to achieve this by just using one feed, but then it might become difficult to distinguish which were internal packages should you want to migrate to a different system in the future.
So i've tried to create a feed to combine to the two, but unsuccessfully:
Create a new NPM feed -> Connect to a ProGet Feed -> Connect to a Feed on this server -> choose 'npm-internal', give it a name etc. If you go to the feed page for this new feed, it says an error occurred while querying connectors for this feed (Connection refused). If you go to the connectors settings for this feed, you can add the npm-external connector, but if you go back to the feed page then you now get 2 connection refused errors.
Version 24.24 (Build 1) - running inside a docker container on Linux