CopyAppFilesToFolder splits a single file path on commas when Test-Path fails, breaking publisher names with a comma

[StefanMaron]

CopyAppFilesToFolder (HelperFunctions.ps1) falls back to splitting a single file path on commas when Test-Path fails on it. If the path contains a comma from a publisher name, the path gets split into two invalid pieces and both report as "File not found," instead of the actual problem being reported.

What I saw: during Run-AlPipeline, a dependency app failed to install with two "File not found" warnings, where a single correct file path was split into two pieces at a comma:

##[warning]File not found: .../Stoneridge Software
##[warning]File not found: LLC_Longhorn Midstream BC Extension_25.2.2147483647.2.app

The file was present at that exact path — I downloaded and inspected it directly. The publisher name is "Stoneridge Software, LLC," and the comma in the publisher name is what gets split.

The code (master, HelperFunctions.ps1, CopyAppFilesToFolder):

function CopyAppFilesToFolder {
    Param(
        $appFiles,
        [string] $folder
    )

    if ($appFiles -is [String]) {
        if (!(Test-Path $appFiles)) {
            $appFiles = @($appFiles.Split(',').Trim() | Where-Object { $_ })
        }
    }
    ...

navcontainerhelper/HelperFunctions.ps1

Lines 577 to 586 in 389bfbc

	function CopyAppFilesToFolder {
	Param(
	$appFiles,
	[string] $folder
	)
	if ($appFiles -is [String]) {
	if (!(Test-Path $appFiles)) {
	$appFiles = @($appFiles.Split(',').Trim() | Where-Object { $_ })
	}

Several callers in Run-AlPipeline.ps1 pass a single path in a loop (e.g. CopyAppFilesToFolder -appfiles $_ -folder $packagesFolder). When Test-Path on that single path returns false, for any reason, the function assumes the string must be a comma-separated list of multiple paths and splits it. A publisher name with a comma turns one missing (or momentarily inaccessible) file into two nonsense paths, and the resulting "File not found" warnings point at the wrong thing.

In my case, this made a real dependency look "missing" to the caller, which then fell back to a different install path (pulling the latest published NuGet package instead of using the app file that was already there), and that fallback package was out of date relative to what I was building against — so the actual failure came out downstream as unrelated compile errors, with no connection back to the comma in the publisher name.

Suggested fix: don't guess that a single string is a comma-separated list. Either require callers to pass an array of paths, or only split on commas when the caller explicitly indicates a list of paths (rather than inferring it from Test-Path failing).

Repro condition: any AL app whose publisher name contains a comma, passed through CopyAppFilesToFolder as a single path that isn't found on first check.