Alternatively, you can use the PS module I've been developing:

$> Install-Module Posh-ProGet
$> Import-Module Posh-ProGet
$> $session = New-ProGetSession -Address 'http://proget.mysite.io:8624' -ApiToken 'mytoken'
$> $feed = New-ProGetFeedObject @{Name='test-feed';FeedType='asset';Active=$true}
$> New-ProGetFeed $session $feed
$> $content = "#My File \n This is a test!"
$> New-ProGetAsset $session $feed.Name "test.md" -ContentType 'text/plain' -Content $Content
$> Get-ProGetAssets $session $feed.Name

# Name     : test.md
# Parent   :
# Type     : application/octet-stream
# Content  : http://proget.mysite.io:8624/endpoints/test-feed/content/test.md
# Created  : 2021-03-30T04:36:21.59Z
# Modified : 2021-03-30T04:36:21.59Z
# Size     : 27
# md5      : 25a7e1e4f8e8c8d387f3e5dde6f6f2a6
# Sha1     : c584e7c125d41a9a8123f69040f30673c66c97bd
# Sha256   : 460c44334aee7966339ad4c9c749aa67b9841dcfd7d67348fc2395a7b8adf7e4
# Sha512   : 293be0c9cfffa1c939c2b711d4165073c3efb200ed25e0adb2bf1f88d0a2343f71a62d99265aa27560630a9643124182ee9774e713bd
           c468d2014681325b8e41

I tried increasing the value in Web.cfg at this location:

<httpRuntime requestValidationMode="2.0" requestPathInvalidCharacters="" maxRequestLength="1342177280" executionTimeout="86400" targetFramework="4.5" />

I've bumped it to 10GB there, restarted the server, but found no difference. I see another setting here:

<requestLimits maxAllowedContentLength="4294967295" maxQueryString="1048576" maxUrl="1048576" />

But that's already set to 32 GB, so I don't think it's the culprit. I'm not using IIS and this appears to be the only web-related configuration I can find.

I have a Chocolatey package that's ~7GB in size and I can't get it to upload using the web UI or by using the choco binary. Looking at the network traffic, it seems to stop dead at ~2GB in size through the web interface, which I'm assuming must be a limit imposed somewhere. What's not clear is if that same limit is imposed on Chocolatey because the choco binary just waits indefinitely and never finishes uploading the package.

I also tried using nuget.exe which eventually times out with:

Response status code does not indicate success: 400 (There must be exactly one package.).

This is rather confusing as I am only pushing a single .nupkg file.

What settings do I need to adjust to support uploading larger Chocolatey packages?

Alternatively, you can use the PS module I've been developing:

$> Install-Module Posh-ProGet
$> Import-Module Posh-ProGet
$> $session = New-ProGetSession -Address 'http://proget.mysite.io:8624' -ApiToken 'mytoken'
$> $feed = New-ProGetFeedObject @{Name='test-feed';FeedType='asset';Active=$true}
$> New-ProGetFeed $session $feed
$> $content = "#My File \n This is a test!"
$> New-ProGetAsset $session $feed.Name "test.md" -ContentType 'text/plain' -Content $Content
$> Get-ProGetAssets $session $feed.Name

# Name     : test.md
# Parent   :
# Type     : application/octet-stream
# Content  : http://proget.mysite.io:8624/endpoints/test-feed/content/test.md
# Created  : 2021-03-30T04:36:21.59Z
# Modified : 2021-03-30T04:36:21.59Z
# Size     : 27
# md5      : 25a7e1e4f8e8c8d387f3e5dde6f6f2a6
# Sha1     : c584e7c125d41a9a8123f69040f30673c66c97bd
# Sha256   : 460c44334aee7966339ad4c9c749aa67b9841dcfd7d67348fc2395a7b8adf7e4
# Sha512   : 293be0c9cfffa1c939c2b711d4165073c3efb200ed25e0adb2bf1f88d0a2343f71a62d99265aa27560630a9643124182ee9774e713bd
           c468d2014681325b8e41

Hi @stevedennis,

Here is the full request from Postman:

PUT /endpoints/test/content/test.md HTTP/1.1
X-ApiKey: <REDACTED>
Content-Type: text/plain
User-Agent: PostmanRuntime/7.26.10
Accept: */*
Postman-Token: 1f29e244-a552-49c6-88b7-87cfc293dd16
Host: proget.mysite.io:8624
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 24
# My file
This is test!

This is the asset that is created:

{
        "name": "test.md",
        "size": 24,
        "type": "application/octet-stream",
        "content": "http://proget.mysite.io:8624/endpoints/test/content/test.md",
        "md5": "a555c6bee6027254fd2dc393fc84d3fa",
        "sha1": "b5bebaad65a6407e230b0f3e2a337196a0246dd4",
        "sha256": "1d8a3f8230963f09c494c0e6156266db66d6b5a4f2491a838739164188633538",
        "sha512": "363578250ddf2d66db3a6d31a7f1b1fc3f43f09db758958fcceb0e16bf0a0ed68365e235670cba59a3157918a9001202d654264e04d8c10cd6a79bc4954bd857",
        "created": "2021-03-30T04:05:17.763Z",
        "modified": "2021-03-30T04:05:17.763Z"
    }

Here are my server details:

{
  "applicationName": "ProGet",
  "releaseNumber": "5.3.25",
  "versionNumber": "5.3.25 (Build 18)",
  "extensionsInstalled": {
    "ProGetCoreEx": "5.3.25",
    "Inedo.SDK": "1.11.0",
    "Amazon AWS": "1.11.2",
    "Azure": "1.11.1",
    "InedoCore": "1.10.3"
  },
  "serviceStatus": "OK",
  "serviceStatusDetail": null,
  "licenseStatus": "OK",
  "licenseStatusDetail": "License key is valid.",
  "replicationHealth": null
}

If you click on an asset in the web UI, it's possible to change the content type of the asset through a link. However, looking through the API docs, I don't see where it's possible to modify the content type of an asset through an API call. It seems that the ProGet server is doing its own check for content type as any value contained within the Content-Type header that is sent with the PUT request is ignored. For example, as a simple test, I uploaded a markdown file and set the Content-Type to text/plain and the ProGet server sets the content type to application/octet-stream. This seems to be the default value because I can upload the file via the web GUI and get the same result.

So in the above case, it's necessary for me to correct the server but I don't see a way of doing it without having to go through the GUI. Am I missing something?

That did it, thanks! TIL that nullable types were a thing :)

It presents an interesting case for Powershell specifically since it's not possible to set a property defined as an integer to the value $null. For example:

class MyClass {
  [int] $myInt
}

$my_class = [MyClass]::new()
$my_class.myInt # 0

$my_class.myInt = $null
$my_class.myInt # 0

My Powershell is not very strong, but from what I'm seeing here, the only viable way to satisfy the data integrity rule is to remove the static typing on my end for these properties. Otherwise, I'd be resorting to some super hacky post-editing of the JSON because there's no case in which Powershell would output a JSON string with null for the value of a statically typed integer.

I'm running into an interesting issue where the API seems to be unhappy when you pass a zero for an integer value instead of a null. For example, when creating a new feed, and passing the below JSON:

{	
  "name": "internal-chocolatey",	
  "alternateNames": null,	
  "feedType": "chocolatey",	
  "description": null,	
  "active": true,	
  "cacheConnectors": true,	
  "dropPath": null,	
  "packagePath": null,	
  "packageStore": null,	
  "allowUnknownLicenses": true,	
  "allowedLicenses": null,	
  "blockedLicenses": null,	
  "symbolServerEnabled": false,	
  "stripSymbols": false,	
  "stripSource": false,	
  "connectors": null,	
  "vulnerabilitySources": null,	
  "retentionRules": [	
    {	
      "deletePrereleaseVersions": false,	
      "deleteCached": true,	
      "keepVersionsCount": 10,	
      "keepUsedWithinDays": 0,	
      "triggerDownloadCount": 0,	
      "keepPackageIds": null,	
      "deletePackageIds": null,	
      "keepVersions": null,	
      "deleteVersions": null,	
      "sizeTriggerKb": 102400,	
      "sizeExclusive": true	
    }	
  ],	
  "packageFilters": {},	
  "packageAccessRules": {},	
  "replication": {	
    "clientMode": null,	
    "serverMode": null,	
    "clientToken": null,	
    "serverToken": null,	
    "sourceUrl": null	
  },	
  "variables": {}	
}

Results in the following error:

547160FeedRetentionRules_CreateOrUpdateRule37`The INSERT statement conflicted with the CHECK constraint "CK__FeedRetentionRules". The conflict occurred in database "ProGet", table "dbo.FeedRetentionRules", column 'TriggerDownload_Count'.

Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 1, current count = 0.

Notice that in the JSON above that the keepUsedWithinDays and triggerDownloadCount are both set to 0. This is what the API appears to be complaining about. If you replace those values with null like so:

...
"retentionRules": [	
    {	
      "deletePrereleaseVersions": false,	
      "deleteCached": true,	
      "keepVersionsCount": 10,	
      "keepUsedWithinDays": null,	
      "triggerDownloadCount": null,	
      "keepPackageIds": null,	
      "deletePackageIds": null,	
      "keepVersions": null,	
      "deleteVersions": null,	
      "sizeTriggerKb": 102400,	
      "sizeExclusive": true	
    }	
  ],
...

The API has no issues creating the new feed. This is problematic because, behind the scenes, the Powershell API I am developing has defined these two properties as integers and the "zero value" for them is 0, not null.

The only option I have is to manually check for these edge cases and convert the zeroes into nulls before sending off the JSON which seems rather silly. Is there a specific reason the API won't accept a zero in this case?

Can confirm the latest version resolves the issue. Thanks!

On the latest version of ProGet (Version 5.3.24 (Build 7)) I am getting weird responses from the API. Example Powershell:

$base_url = 'http://localhost:8624'
$headers = @{
    'X-ApiKey' = $api_key
}

# Add the Powershell feed
$feed_endpoint = $base_url + '/api/management/feeds/create'
$request = @{
    name        = 'internal-powershell'
    feedType    = 'powershell'
    description = 'Internal Powershell feed for hosting modules'
    active      = $true
}

Invoke-RestMethod -Method Post -Uri $feed_endpoint -ContentType 'application/json' -Headers $headers -Body ($request | ConvertTo-Json)

This is returning what appears to be a double response:

{
	"name": "internal-powershell",
	"alternateNames": [],
	"feedType": "powershell",
	"description": "Internal Powershell feed for hosting modules",
	"active": true,
	"cacheConnectors": true,
	"allowUnknownLicenses": true,
	"allowedLicenses": [],
	"blockedLicenses": [],
	"symbolServerEnabled": false,
	"stripSymbols": false,
	"stripSource": false,
	"connectors": [],
	"vulnerabilitySources": [],
	"retentionRules": [],
	"packageFilters": {},
	"packageAccessRules": {},
	"replication": {},
	"variables": {}
} {
	"name": "internal-powershell",
	"alternateNames": [],
	"feedType": "powershell",
	"description": "Internal Powershell feed for hosting modules",
	"active": true,
	"cacheConnectors": true,
	"allowUnknownLicenses": true,
	"allowedLicenses": [],
	"blockedLicenses": [],
	"symbolServerEnabled": false,
	"stripSymbols": false,
	"stripSource": false,
	"connectors": [],
	"vulnerabilitySources": [],
	"retentionRules": [],
	"packageFilters": {},
	"packageAccessRules": {},
	"replication": {},
	"variables": {}
}

It's throwing Powershell off of course due to having two root elements. I confirmed this behavior using Postman, so it's not anything unique with Powershell. Can anyone else confirm they are seeing this? It seems like it might be a bug.