Compiler Error - Specified part does not exist in the package (Compiler Version 18.0.37.11445)

[Joneleth84]

1. Describe the bug
Compilation of files (at least RDLC files) that contain a bracket in its filename break the compiler with error message "Specified part does not exist in the package".

2. To Reproduce

1. Create a Report
2. Add a RDLC file that contains a bracket in the file name, i.e. ( )
3. Compile with AL compiler
4. Compiler throws Error Message "Specified part does not exist in the package"

3. Expected behavior
Brackets in filenames should not break the compiler logic.

4. Actual behavior
A binary check of the app files show that certain chars are encoded compared with a former compiler version, i.e. 17.XXX

5. Versions:
AL compiler version 18.0.37.11445

Internal work item: AB#638488

[TKapitan]

@esbenk I can confirm we see this issue across multiple next-major builds in our pipelines, at least from artifact https://bcinsider-fvh2ekdjecfjd6gk.b02.azurefd.net/sandbox/29.0.50953.0/au

[kine]

I confirm that we have this even when using the preview version of compiler for our current projects on older BC versions (e.g. BCv27.3 etc.).

[RonKoppelaar]

I saw following behavior:

Using AL toolpackage version
'18.0.37.11445-beta' (latest) against Insider build BC29 ==> Succeeded.

Using AL toolpackage:
'18.0.37.11445-beta' (latest) against build BC28.2 ==> Failed with mentioned error

Using AL toolpackage:
'18.0.33.65164-beta' against build BC28.2 ==> Succeeded.

How should we proceed with this?

[RonKoppelaar]

I can confirm this bug is not only relates to report layout files, but in fact any AL object with specific characters will fail.
I used following script to identify failing filenames:

$root = '<Your source root folder>'
Get-ChildItem -LiteralPath $root -Recurse -File | ForEach-Object {
    $rel = $_.FullName.Substring($root.Length)
    $bad = [regex]::Matches($rel, '[^A-Za-z0-9 ._\\\-]') | ForEach-Object { $_.Value }
    if ($bad) {
        [PSCustomObject]@{
            Path     = $rel
            BadChars = ($bad | ForEach-Object { "'$_' (U+{0:X4})" -f [int][char]$_ }) -join ', '
        }
    }
}

In my case it found following
Path                                                                     BadChars
----                                                                     --------
\BaseApp\src\KopiërenOGMSteksten.Report.al                               'ë' (U+00EB)
\BaseApp\src\Werksoortenkopiëren.Report.al                               'ë' (U+00EB)
\BaseApp\src\Housing\Contract\Elements\Elementenkopiëren.Report.al       'ë' (U+00EB)
\BaseApp\src\Housing\OwnersAssociation\EenhedennaarVvEkopiëren.Report.al 'ë' (U+00EB)
\BaseApp\src\Housing\WRV\WoonnetAanbiedcategorieën.Page.al               'ë' (U+00EB)
\BaseApp\src\RealEstate\Projects\Kopiërennaarvanprojectmodel.Report.al   'ë' (U+00EB)
\EmpireProfiles\src\Permissions\cdalgdwpagina's.PermissionSetExt.al      ''' (U+0027)

Only the last filename cdalgdwpagina's.PermissionSetExt.al was an issue due to the "single quote" in the filename.
The filenames with 'diaeresis' like ë and ï were not giving trouble.

After fixing the problem filenames I was able to build both BC28 and BC29 using the latest AL toolbox: 18.0.37.11445-beta

I hope these insights help MSFT to solve the problems in the compiler, and the script might help partners to bypass the issue when not yet solved.

[Subhavarman]

Thanks, RonKoppelaar.

I ran your script across our projects. Besides ( ) and & in .al file names, it also flagged our .xlf (translation files,) whose names contain & (U+0026),

Your confirmed cases were all AL object files (.Report.al, .Page.al, and .PermissionSetExt.al), so I would like to confirm:

1. Does this affect non-AL packaged files, too – specifically .xlf translation files (and other resources) - or only AL object source files?
2. Can you confirm the full list of failing characters? So far reported: (U+0027) & (U+0026), and () / [] (U+0029). And that space, period, dash, and underscore (and diaeresis like ë/ï) are safe?
3. Which platform/runtime introduced this, and which version will fix it?

For context, we also encountered an issue at publish time (Specified part does not exist in the package, HTTP 422): a byte identical .app publishes on 29.0.50917.0 but fails on 29.0.52040.0.

Thanks.

[someC0d3r]

FYI This also affects bad chars in directory names, e.g. app/MyFolder (Term)/SomeAppFile.al as we have experienced this error.