Publish-Module fails to publish when large number of functions are exported

[Texernie]

Publish-Module creates an invalid nuspec file when a large number of functions are exported in a powershell module. The problem is that down in Publish-PSArtifactUtility, it brute forces all of the exported function names into the tags. My particular case resulted in a tag field around 11000 characters, way over the 4000 limit. I am publishing to a self-hosted nuget gallery, but it is based upon the current production branch.

It would be nice if it either truncated the values at 4000 characters with a warning, or allow a total override of the tags.

Steps to reproduce

Create a module with many functions to export. Mine has 116 distinct functions.
$functionNames = (Get-ChildItem '.\MyModule\Scripts' *.ps1).BaseName
Update-ModuleManifest `
    -Path '.\MyModule\MyModule.psd1' `
    -FunctionsToExport $functionNames 

Publish-Module -Path (resolve-path .\MyModule)  | Out-Null

Expected behavior

Publishing of the module to succeed and a nuget package exist in the repository.

Actual behavior

Publish-PSArtifactUtility : Failed to publish module 'MyModule': 'Response status code does not indicate success: 400 (A nuget package's Tags
property may not be more than 4000 characters long.).
'.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\2.0.1\PSModule.psm1:10859 char:17
+ ...             Publish-PSArtifactUtility @PublishPSArtifactUtility_Param ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : FailedToPublishTheModule,Publish-PSArtifactUtility

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      5.1.17134.228
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17134.228
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

> Get-Module -ListAvailable PowerShellGet,PackageManagement

    Directory: C:\Program Files\WindowsPowerShell\Modules


ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     1.1.7.2    PackageManagement                   {Find-Package, Get-Package, Get-PackageProvider, Get-PackageSource...}
Binary     1.0.0.1    PackageManagement                   {Find-Package, Get-Package, Get-PackageProvider, Get-PackageSource...}
Binary     1.0.0.0    PackageManagement                   {Find-Package, Get-Package, Get-PackageProvider, Get-PackageSource...}
Script     2.0.1      PowerShellGet                       {Find-Command, Find-DSCResource, Find-Module, Find-RoleCapability...}
Script     1.0.0.1    PowerShellGet                       {Install-Module, Find-Module, Save-Module, Update-Module...}

> Get-PackageProvider -ListAvailable

Name                     Version          DynamicOptions
----                     -------          --------------
DockerProvider           0.0.0.3          Update
msi                      3.0.0.0          AdditionalArguments
msu                      3.0.0.0
nuget                    2.8.5.208
NuGet                    2.8.5.210        Destination, ExcludeVersion, Scope, SkipDependencies, Headers, FilterOnTag...
PowerShellGet            1.0.0.1          PackageManagementProvider, Type, Scope, AllowClobber, SkipPublisherCheck, ...
Programs                 3.0.0.0          IncludeWindowsInstaller, IncludeSystemComponent

PS> get-command publish-module

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Function        Publish-Module                                     2.0.1      PowerShellGet

[Texernie]

Edited the request to show that the issue still exists in PowershellGet 2.0.1.

[bmanikm]

@Texernie Since your repository is a self-hosted nuget gallery, please consider removing the limitation on tag limit. Another option is to update the PowerShellGet module temporarily on your machine to limit/remove tags entry. Let us know if this issue can be reproducible when you publish a module with 116 commands to the PowerShell Gallery.

I agree with you on adding an optional switch parameter to the Publish-Module cmdlet to not any additional tags for the exported commands.

[Texernie]

I am a little hesitant to expand the tag limit on our Nuget gallery since it is so close to nuget.org's site and I am really unfamiliar with their database update scheme. We basically have the private gallery so we can use the Nuget technology without exposing our private data. It has only been modified with branding and where it stores the files. In all other respects, it is an identical copy of nuget.org.

I am attempting to work around this issue by splitting up my module into 4 smaller ones, then have one module that requires all of the sub modules.

PowershellGallery dealt with the test file I put up there fine. It had 8248 characters in the tag field (Version 1.0.0.1). I modified it to make the tags even longer and it came in at 9208 characters (Version 1.0.0.2). This package can be hard deleted as it is nothing but test files that have no content in them. I have already de-listed them.

https://www.powershellgallery.com/packages/TestPowershellPackage/1.0.0.1
https://www.powershellgallery.com/packages/TestPowershellPackage/1.0.0.2

[Texernie]

@bmanikm I took a little time this morning and found out that disabling the 4K character limit on the NugetGallery was pretty easy and did not require database modifications. I am currently over my hurdle, although this request is still a nice request since others might hit the same issue.

[alerickson]

I'm going to close this issue for now, we can re-open if there's any other problems associated with this or if someone else brings it up.

[Texernie]

The code change is still a good idea. If the issue is closed, how would anyone know to pick up the issue? I simply did a work around, which not everyone may be able to do.