[Feature Request] Get-ChocolateyBins and Long File Paths and .exe's

[alexinslc]

NOTE: This has been brought up in the Chocolatey google group here. I hope it's okay I've put it in here as a feature request.

I've got a package I'm working on that has a deeply nested file structure. I've found this error when trying to install the package.

get-childitem : The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
At C:\ProgramData\chocolatey\chocolateyinstall\functions\Get-ChocolateyBins.ps1:17 char:16
+       $files = get-childitem $packageFolder -include *.exe -recurse
+                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ReadError: (C:\ProgramData\...odules\argparse:String) [Get-ChildItem], PathTooLongException
+ FullyQualifiedErrorId : DirIOError,Microsoft.PowerShell.Commands.GetChildItemCommand

Digging a little deeper, it looks like this is the line of code it doesn't like.

I don't really need this "search for .exe's" feature and would like to explicitly tell Chocolatey where my .exe files are because the ones I really need are at a MUCH higher level than the rest of the project.

Feature request is to create a way of silently ignoring the error, skipping the file(s), or explicitly defining my .exe's.

As far as I know, this is a limitation on windows and isn't something you can easily get around.

Thanks!

[ferventcoder]

I'm thinking a file named something like .bins that points to a relative path in the package where all of the exe/batch files are. If found, choco will only evaluate this file (but .gui and .ignore files will still be used).

[ferventcoder]

Actually scratch that name, nuget has a bug on names of files/folders that start with dot .. It's a really stupid limitation, I don't remember if we override it with choco.exe or not.

[jberezanski]

Regardless of NuGet limitations, dot-files (i.e. files with empty name) can generally be a pain to work with, such as when "show extensions for known file types" is unchecked and the file is associated with a program, e.g. a text editor. Besides, they look definitely non-Windows.
I'd suggest something like shimlist.txt for the name, with the ability to specify both directories and individual files.

A cleaner solution would be to extend the nuspec schema, but I seem to recall NuGet not liking that...?

[ferventcoder]

@jberezanski agreed.

And I think ultimately extending the nuspec schema. We are definitely going in that direction.