Hi @atripp,
currently we are using ProGet 2025.14, so we first check if an upgrade of ProGet 2024.19 or higher would fix the Issue.
I will reply to this topic if the Issue always exists.
Best regards
Hi @atripp,
currently we are using ProGet 2025.14, so we first check if an upgrade of ProGet 2024.19 or higher would fix the Issue.
I will reply to this topic if the Issue always exists.
Best regards
Hi there,
I currently want to evaluate the possibility to of using a nuget Feed as Symbol-Server (configured as Mixed) for our self compiled applications.
To do this I attached the *.pdb File into a simple nuget package based on the following sample nuspec File:
<?xml version="1.0"?>
<package >
<metadata>
<id>Sample Tool</id>
<version>1.0.0</version>
<authors>Our Company</authors>
<description>Native C++ Application</description>
</metadata>
<files>
<file src="sample_tool.pdb" target="lib" />
</files>
</package>
I uploaded this package into the feed, which shows me the package and also on the Symbols tab the pdb file with Id (58544d524263363572307558336f79534a39392b45413d3d) and Age (1).
Now I configured the windbg to interact with the Feed Symbol-Server (set Symbol path to <Server-URL>/symbols/<feed-name>) and open the Executable for this pdb File.
I activated than the noisy symbol loading (!sym noisy) because there are some issues while loading the symbols. The Log shows me that windbg want to download the pdb File from the a different URL, because the id is different (/symbols/<feed-name>/sample_tool.pdb/0511335DB9CE4BAF97DE8C9227DF7E101/sample_tool.pdb
).
I analysed our PDB File and it seems that the ID generation of ProGet has possibly a issue because a call of llvm-pdbutil dump --summary sample_tool.pdb results in the following Information:
After combining this data (GUID + Age) the result is 0511335DB9CE4BAF97DE8C9227DF7E101 which is the same as Windbg want to download 0511335DB9CE4BAF97DE8C9227DF7E101.
Do you have any suggestions what I can do to use this feature?
Best regards
For now we try to use a workaround - It would be really helpful for us if this would be implemented into the code in the future.
Hi @atripp,
thanks for the explanation.
I can understand that you are not willing/able to change this behavior. Now I will check if it is possible for us to modify the underlying wget call to allow downloading of the files from ProGet.
Best regards
Hi @atripp,
thanks for your fast answer.
Our script only downloads files from the ProGet-Server with wget on Linux and username:password (cannot be changed as simple). As we are using the API-Keys to authenticate with the server, so the wget call is the following:
wget --user api --password <api-key> <Download path>
After running this command I get a 401 from the Server. If I add the --auth-no-challenge argument like in the following snipped:
wget --user api --password <api-key> --auth-no-challenge <Download path>
than the Download runs without any issues.
The download also works without the --auth-no-challenge argument if I allow the download for Anonymous users.
I also checked if a download works if I send the Auth-Header manually with wget.
# generate base64 Encode Credentials
echo -n 'api:<key>' | base64
wget --header="Authorization: Basic <base64 Credentials>" <Download path>
This works also without any issues.
Hi there,
today I want to implement a file download over a toolkit which we use in our development process. This toolkit (which runs on linux) will download files from the server (now ProGet) over wget. The username and password will be used from wget over a .netrc file.
If I run a download of a file (I tested asset download and pypi-package download) with wget the ProGet-Server will response with 401 Unauthorized.
---response end---
401 Unauthorized
Registered socket 3 for persistent reuse.
Skipping 105 bytes of body: [You are not authorized to perform the Feeds_DownloadPackage task on this feed anonymously. Please log in.] done.
Unknown authentication scheme.
Username/Password Authentication Failed.
If I add the argument --auth-no-challenge to the wget call than the download will finish successfully but I this is more a workaround for this issue. As a side note the download of the same file over curl run without any issues and without extra arguments.
Are there any possibilities to fix this issue?
Best regards.
Would using an external database resolve that issue? So not using the embedded one?
Is it possible to switch to an external one with the instance already running with the embedded one?
Hi @atripp
thanks for your response and the description. We want to store some cache informations generated from yocto, onto our ProGet-Asset to share it between the developers. Unfortunately the generated filename can not be shorted, but it seems so that the maximum length of the filenames generated by yocto are 254.
Do you think it could be possible to modify the code/database to allow fitting this maximum?
Thanks
@Dan_Woolf Thanks for the quick reply - so this is nothing we can configure at the moment?
When uploading we do get the following error:
Failed to upload sstate:go-cross-canadian-aarch64:x86_64-nativesdk-poky-linux:1.17.13:r0:x86_64_x86_64-nativesdk:10:014a9fde37c442d487899c82c313f81e6bb015b8eaddfd10b257fda1e3e88afb_deploy_source_date_epoch.tar.zst.sigi: 22001: value too long for type character varying(200)
Npgsql.PostgresException (0x80004005): 22001: value too long for type character varying(200)
at Npgsql.Internal.NpgsqlConnector.ReadMessageLong(Boolean async, DataRowLoadingMode dataRowLoadingMode, Boolean readingNotifications, Boolean isReadingPrependedMessage)
at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token)
at Npgsql.NpgsqlDataReader.NextResult(Boolean async, Boolean isConsuming, CancellationToken cancellationToken)
at Npgsql.NpgsqlDataReader.NextResult(Boolean async, Boolean isConsuming, CancellationToken cancellationToken)
at Npgsql.NpgsqlCommand.ExecuteReader(Boolean async, CommandBehavior behavior, CancellationToken cancellationToken)
at Npgsql.NpgsqlCommand.ExecuteReader(Boolean async, CommandBehavior behavior, CancellationToken cancellationToken)
at Inedo.ProGet.Data.PostgresDatabaseContext.PostgresCommand.ExecuteReaderAsync(CancellationToken cancellationToken) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\Data\PostgresDatabaseContext.cs:line 392
at Inedo.Data.DatabaseContext.DbResult.CreateAsync(IGenericDbCommand command, DatabaseContext context, DateTimeOffset startTime, Stopwatch stopwatch)
at Inedo.Data.DatabaseContext.ExecuteInternalAsync(String storedProcName, GenericDbParameter[] parameters, DatabaseCommandReturnType returnType)
at Inedo.Data.DatabaseContext.ExecuteNonQueryAsync(String storedProcName, GenericDbParameter[] parameters)
at Inedo.Data.DatabaseContext.ExecuteScalarAsync[TResult](String storedProcName, GenericDbParameter[] parameters, Int32 outParameterIndex)
at Inedo.ProGet.Feeds.Assets.AssetFeed.AddExistingFileAsync(String fullPath, String contentType) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\Feeds\Assets\AssetFeed.cs:line 159
at Inedo.ProGet.WebApplication.FeedEndpoints.Assets.AssetContentHandler.CompleteMultipartUploadAsync(AhHttpContext context, AssetFeed feed, String url, Boolean ignoreContentType) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\WebApplication\FeedEndpoints\Assets\AssetContentHandler.cs:line 318
at Inedo.ProGet.WebApplication.FeedEndpoints.Assets.AssetContentHandler.UploadFileAsync(AhHttpContext context, WebApiContext apiContext, AssetFeed feed, String url, PutMode mode, Boolean ignoreContentType) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\WebApplication\FeedEndpoints\Assets\AssetContentHandler.cs:line 170
at Inedo.ProGet.WebApplication.FeedEndpoints.Assets.AssetFineUploadHandler.TryProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, AssetFeed feed, String relativeUrl) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\WebApplication\FeedEndpoints\Assets\AssetFineUploaderHandler.cs:line 29
Exception data:
Severity: ERROR
SqlState: 22001
MessageText: value too long for type character varying(200)
Where: PL/pgSQL function "Assets_FindFromPath"(integer,text,boolean,boolean,integer,text,xml) line 18 at assignment
SQL statement "SELECT found."@AssetItem_Id",
found."@CanonicalAssetPath_Text",
found."@Inherited_CacheConfiguration_XML"
FROM "Assets_FindFromPath" (
"@Feed_Id",
"@AssetPath_Text",
"@IncludeDeleted_Indicator",
"@AllowCaseInsensitiveMatch_Indicator",
"@AssetItem_Id",
"@CanonicalAssetPath_Text",
"@Inherited_CacheConfiguration_XML"
) AS found"
PL/pgSQL function "Assets_GetItemFromPath"(integer,text,boolean,boolean,text,xml,xml) line 6 at SQL statement
File: varchar.c
Line: 637
Routine: varchar
::Asset Upload Error on 01/14/2026 10:02:19::
Anyone able to help on this?
Hi @stevedennis,
thanks for your reply, it would be really nice if this feature could be implemented. We would chat about this with our point of contact.
Thanks,
Florian
Hi there,
are there any possibilities to promote a package (internal feed) to next feed if the build is promoted?
The reason for this question is that my idea for a good workflow would be as followed:
Actually we should start a lookup for each package in the Package in the Build after promotion and should promote each Package manually (over Web-UI or pgutil-CLI) to another feed.
Would this be a possible workflow solution or there any other suggestions to work with package/build/promotion?
Best regards,
Florian
Hi there,
after evaluating a Conan Feed in ProGet it saw a confusing thing in the detection.
First of all I configured the License Check in System as follows:
I created a really simple Conan Recipe which only defines some basic parameters (no files added):
class BasicConanfile(ConanFile):
name = "test"
version = "1.0"
description = "A test recipe"
license = "Apache-2.0"
After creating this and upload it to the Conan-Feed, I get the following correct information from Proget (Package Overview):
⛔ Package is Noncompliant
This package analysis resulted in a Noncompliant result because of an Unacceptable License (Apache-2.0).
Now I added Apache-2.0 to the Compliant Licenses and get the following information from Proget (Package Overview):
⚠ Warning: Use with Caution
No license detected
The Metadata for this Package shows me the following
License: None, Known type (Apache-2.0)
so I added the Apache-2.0 License-File to my sources of the Conan-Recipe and reuploaded it but the message from Proget is the same:
(Package Overview):
⚠ Warning: Use with Caution
No license detected
But the Metadata for this Package now shows me the following
License: SPDX Expression (Apache-2.0), Known type (Apache-2.0)
Could you check this?
Best regards
Florian
Hi there,
we are currently evaluating the use of Proget and found a possible limitation for our use case which referes to universal packages.
We have some kind of components which are build with third-party components (Licensed under MIT, Apache or so) or closed-source components.
The built components should be stored in a universal package, because it does not feed in a another package type (conan, rpm, deb, ...). It would be really nice if this package would show which licenses are involved in the build so that the Manager could check if all used licenses are compliant.
The third-party components could be something like the SoC-Vendor SDK which not really fit into a conan package to deploy it, it would better fit into a universal package but on this we could not set the license.
Is it possible to implement this feature or there other possible ways to build this in Proget.
Best regards,
Florian