Thanks I will take a look at the latest version.

Do Inedo recommend using pgutil instead of the usual HTTP APIs going forward?

Will their be feature parity between the API and pgutil ?

Just wondering what we should be using as the best way to programmatically manage ProGet going forward.

Thanks

@atripp thanks for confirming

Hi,

I have been able to successfully set the permissions for an Admin API keys that has full system access by using the stored proc 'ApiKeys_CreateOrUpdateApiKey'

I am using the same method to create an API key which needs to be able to publish packages to all feeds, can you tell me how the XML should be set?

This works for my Admin System API key

'<Inedo.ProGet.ApiKeys.ApiKey Assembly="ProGetCoreEx">' +
'<Properties ' +
'AllowPackagePromotionApi="False" ' +
'AllowRepackagingApi="False" ' +
'AllowFeedManagementApi="False" ' +
'AllowWebhooksApi="True" ' +
'AllowConnectorHealthApi="True" ' +
'AllowFeedsApi="True" ' +
'AllowDockerBlobReaderApi="False" ' +
'AllowSbomApi="True" ' +
'AllowSbomUpload="True" ' +
'UseApiKeyTasks="False" ' +
'AllowNativeApi="True" ' +
'DoNotLogRequest="False" ' +
'DoNotLogResponse="False" />' +
'</Inedo.ProGet.ApiKeys.ApiKey>'

This adds the api Key but gives me no permissions, the check box to 'Add/Repackage' is not getting checked.
I want to give the API key access to Add/Repackage on all feeds
I am using this XML:

'<Inedo.ProGet.ApiKeys.ApiKey Assembly="ProGetCoreEx">' +
'<Properties ' +
'AllowPackagePromotionApi="False" ' +
'AllowRepackagingApi="False" ' +
'AllowFeedManagementApi="False" ' +
'AllowWebhooksApi="False" ' +
'AllowConnectorHealthApi="False" ' +
'AllowFeedsApi="False" ' +
'AllowDockerBlobReaderApi="False" ' +
'AllowSbomApi="False" ' +
'AllowSbomUpload="False" ' +
'UseApiKeyTasks="True" ' +
'AllowNativeApi="False" ' +
'DoNotLogRequest="False" ' +
'DoNotLogResponse="False" />' +
'</Inedo.ProGet.ApiKeys.ApiKey>'

Are there any docs that explain these permissions or are you able to help me to see where I am going wrong?

thanks

Thanks

At present, I am building several ProGet servers using the same license key in the installation which seems to be working ok until I get to the activation stage.

Instead of activating successfully, ProGet throws up a manual activation required box, it asks me to logon to myinedo.com and paste a license key and machine UID to retrieve the activation code. Is it doing this because the license key has already been activated on a different ProGet server ?
Is there anyway to get round this with the free version? Is this expected in the free version?

Hi,

I see in the roadmap for ProGet 2024 you are restricting the Delete API to 10 per hour, what is the actual API endpoint name this applies to?

I can't see anything in the notes, but are you deprecating any of the native APIs?

Thanks

@atripp do you know the license activation URLs it will need to hit to activate?
This is so we can allow firewall access

Is it possible to programmatically activate a license via the API or stored proc?
From browsing the native api and stored procs I don't see anything that stands out.

As I understand it, I should be able to activate the same license key multiple times as long as it's the free edition

Thanks

Is there a preferred approach to resetting the Proget Admin password?
I am automating the Proget build and want to reset the Admin password at build time.

I see you can use the Proget.Service.exe to reset the password to defaults but not actually pass in your own secure password.

It seems there is an API documented below that lets you reset the password, but I am having issues with this as Invoke-RestMethod passes a JSON body to the API which is of type string, and the API expects type Bytes

Am I over thinking this, I'm hoping there is an easier way to set the proget admin password to something more secure

Common API reference snippet
Sets the password using "new Rfc2898DeriveBytes(plainTextPassword, 10, 10000)" in C#, with .GetBytes(20) for @Password_Bytes and .Salt for the @Salt_Bytes
User_Name (String)
Password_Bytes (Byte[])
Salt_Bytes (Byte[])

thanks

I am looking to Apply the ProGet Free License found in Administration > Licensing & Activation via the API

Is this possible to do via API or StoredProc?
Can I simply use the Free License Key I already have?
Do I need a different License key for each instance of ProGet Free, or can I use the same License Key for all instances?
Will the License key be permenant and ok to use? (As long as I dont trigger any violations of course)

I see the API guide for licenses here https://docs.inedo.com/docs/proget-licenses-api but do not see an API to apply the main central License, is there something I am missing?

UPDATE: Have seen you can apply the License Key at install as an argument to the hub installer with LicenseKey=
So I guess the only question now is are you ok to install multiple ProGet instances with the same Free License key?

thanks

@atripp thanks for confirming.

Another question.
This article https://docs.inedo.com/v1/docs/proget-bulk-import-with-droppath shows the GUI option "Delete package files from path after import".
When configuring the dropPath, we would like to stop proget deleting the package after import, is this possible? I dont see an option for this in the advanced settings.
Only seems to be available for one off bulk imports via the GUI?

To confirm, We would not be publishing packages and overwriting them, we would only publish new versions of packages to the dropPath so they then get picked up by Proget.

So the question here is still the same, If lots of computers are trying to pull down a PowerShell module called 'MyModule' (default to get the latest version), and someone is releasing a new version of this module by copying a nupkg to the dropPath, I wanted to check that Proget would still serve the old module fine until the new version had been released successfully.

I ask this because the internal version of NuGet server (https://learn.microsoft.com/en-us/nuget/hosting-packages/nuget-server )itself had an issue with this, when new modules were being ingested by nuget server, it sometimes caused errors for users trying to install that module from the feed.

Good to know it will retry if a lock is detected.
Also good to know other folks are using dropPaths as an intermediate to publish packages to Proget.

thanks

Hi,

I've been looking at Progets dropPath feed property here and have a few questions:
https://docs.inedo.com/docs/proget-feed-storage

From reading about this property it says it's primarily used for bulk uploads of packages from a local or unc path.
I would like to use this feature to also upload/publish ad-hoc packages, i.e. If someone releases a new nuget package and copies this to the dropPath, ProGet would pick this change up and publish to the feed.

Are there any downsides to using dropPath in this way? And is anyone else using dropPath this way?

I guess the main question here is, is it suitable for incremental package changes as opposed to just bulk uploads?

Other questions are:
Can ProGet handle situations where multiple computers are trying to install a module from the feed while at the same time that module is being updated by the dropPath feature?

Could these be potential file locking situations where a package is copied to the drop path and ProGet is trying to access it in the dropPath?

Just to close this thread off.

I tried below but no joy:
Rebooting server several times
Server is not under any load
All other feed related API's worked fine
Re-installed proget

Resolved:
Re-installed proget and re-created DB

Using windows server and IIS
Only using Proget

Trying twice in a row does not work either

IIS logs show error http 500
/api/management/feeds/create - 443 - ip-address Mozilla/5.0+(Windows+NT+10.0;+Microsoft+Windows+10.0.22631;+en-US)+PowerShell/7.4.1 - 500 0 0 30006

FYI
The List API works fine
GET /api/management/feeds/list

Hi,
I'm creating a new feed via the API:

$headers = @{
'Content-Type' = 'application/json'
'x-apikey' = $apiKey
}
$body = @{
name = $FeedName
feedType = $FeedType
active = 'true'
}

$params = @{
    Uri     = "https://proget-dev/api/management/feeds/create"
    Method  = 'POST'
    Body    = ($body | ConvertTo-Json)
    Headers = $headers
}

Invoke-RestMethod @params

This returns the error:
Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
The statement has been terminated.

The POST looks correct since if i change the api-key to something that does not have rights it return 403 forbidden

Is there anything to check whats going on here?

thanks

@atripp I looked at the native API but creating or updating the key was missing.

I've now looked at creating the key via stored procedure as you said.

Is there a link or blog where you publish your upcoming features such as these new APIs?
Do you know when the 2024 version will be released?

Thanks

Hi,
I am automating the install and configuration of a ProGet server and would like to know if there is a way to create new API keys using an API ?

I was planning to use the Pseudo Key option with the Admin account to login and setup the API keys I require, but this means I need some programmatic way of managing the API keys and I don't see an API listed for this on the ProGet forums?

Any ideas to get around this ?

Thanks

So its early days but performing the basic Functions from both the PowerShellGet and PSResourceGet modules seems to work as expected without issue, i.e. Find-Module, Find-PSResource, Install-Module, Install-PSResource, Publish-Module, Publish-PSResource work well.

I guess the main reason for asking this question was to check that you guys keep track of these modules released by Microsoft since they are widely used and its nice to know support is on hand if necessary. Its always comforting to know that a vendor is keeping track of issues on platforms such as GitHub etc....

thanks for prompt replies.