txt2al: illegal character in Path - caused by "{targetName}"

[ralf-escher]

After creating DELTA files with Compare-NAVApplicationObject, I got several error messages while using txt2al.exe:

----ERROR----
Error converting file: C:\Users\ralf.escher\Documents\Delta-Industry\DELTA\TAB7316.DELTA
Illegales Zeichen im Pfad = illegal character in Path

this occurs with BC14, CU2 (build 34251, german version) everthing is fine with the older CU1 (build 32600) version, which I am using at the moment as fallback.

Due to a hint from #3707 I now used --stacktrace

Txt2Al.exe --source=DELTA --target=AL --stacktrace 

----ERROR----
Error converting file: C:\Users\ralf.escher\Documents\Delta-Industry\DELTA\TAB99000830.DELTA
Illegales Zeichen im Pfad.
   bei System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional)
   bei System.IO.Path.Combine(String path1, String path2)
   bei Microsoft.Dynamics.Nav.Txt2AlConverter.FileNameExporter.GetPathToResourceFile(String sourceTxtFilePath, String newFileName)
   bei Txt2Al.Program.GetPathToNewAlFile(String txtFilename, ApplicationObject ao, FileNameExporter fileNameExporter, Boolean rename)
   bei Txt2Al.Program.ExportApplicationObject(Tuple`2 fileAndApplicationObject, AlExporterCommandLineOptions cmdLineOptions, AlExportOptions exporterOptions, IDotNetDeclarationExtractor dotNetExtractor, ITranslationExtractor translationExtractor, IEnumDeclarationExtractor enumExtractor, ConcurrentQueue`1 errorsStorage, FileNameExporter fileNameExporter)

It seems like the routine has problems for table- and pageextensions.

Another unsovled issue with txt2al.exe = #4581

[atoader]

@ralf-escher we will look into this. Have you tried moving your input files to a location that does not contain "tricky" characters in the path?

[ralf-escher]

Yes. Also tried now "C:\Temp\AL", still with the same result:

----ERROR---- Error converting file: C:\Temp\AL\DELTA\TAB99000830.DELTA Illegales Zeichen im Pfad.

Generation with the CU1 Version works.

[Kowa63]

Do you have any "tricky" characters in the object names like "'´`/* etc. ? Relating to this article here, these can cause issues in future. https://freddysblog.com/2019/08/02/organizing-your-al-files/

[ralf-escher]

No, we kept the standard names (for the moment) The delta file itself contains CaptionML with german umlaut

OBJECT Modification "Planning Routing Line"(Table 99000830)
{
  OBJECT-PROPERTIES
  {
    Date=20190723D;
    Time=120000T;
    Version List=NAVW114.03,COMPL1.00;
  }
  PROPERTIES
  {
    Target="Planning Routing Line"(Table 99000830);
  }
  CHANGES
  {
    { Insertion         ;InsertAfter="Ending Date-Time"(Field 99);
                         ChangedElements=FieldCollection
                         {
                           { 5043040;;Belongs to Operation No.;Code10    ;CaptionML=[DEU=Gehört zu Arbeitsgangnr.;
                                                                                     ENU=Belongs to Operation No.];
                                                                          Description=COMPL1.00 }
                         }
                          }

-Like mentioned before- the older version of Txt2Al.exe has no problems with these delta files.

[ralf-escher]

files which have been successful created look like: tableextension5042664.TableExt-Location.al

maybe tables like "Planning Routing Line" create a new AL object name which is too long?

[ralf-escher]

Same story for the CU3 (Build 35570) version. CU1 version works, CU2 & CU3 versions do not.

[ralf-escher]

I could isolate the problem about the generated file name:

PS C:\Temp> Txt2Al.exe --source=DELTA --target=AL
----ERROR----
Error converting file: C:\Temp\DELTA\TAB99000830.DELTA
Illegales Zeichen im Pfad.
Total Time: 0:00:00,4279911
Errors: 1

Now using the extensionObjectFileNamePatternparameter with a different pattern (than default):

PS C:\Temp> Txt2Al.exe --source=DELTA --target=AL --extensionObjectFileNamePattern "{name}.{type}"
Writing: C:\Temp\AL\tableextension70000001.TableExt.al
Formatting: C:\Temp\AL\tableextension70000001.TableExt.al
Total Time: 0:00:00,7960519
Errors: 0

as soon as I use {targetName} within the extensionObjectFileNamePattern parameter, the function shows that error. Since {targetName} is part of the default pattern: {name}.{type}-{targetName} it's obvious why it's crashing all the time

[Andri-Wianto]

Replicated on W1 CU 3 Spring Release BC140.

Thanks @ralf-escher for reporting this. I experience the same error message, and I can confirm that your work-around is working.

And you are correct about the cause is the {targetName}.

Hence, I did an experiment and I found that those problem happened for multiple words {targetName}, such as: "G/L Entry", "Sales Line", "Planning Routing Line", "Warehouse Receipt Header", but it works for Customer, Items.

Then I realized that, those multiple words are surrounded by the double quote, and this double quotes are forbidden in the file name, like tableextension70000001.TableExt-"Planning Routing Line".al. And yes, you are correct about it seems like the routine has problems for table extensions and page extensions, because only extensions that create AL file name that does not remove the double quote.

While I check the other than extension, it is like this: PriceandDiscManagement.Codeunit.al

To confirm this, you can open your delta CAL code in notepad, then search for

  PROPERTIES
  {
    Target="Planning Routing Line"(Table 99000830);
  }

then change it to remove the double quote and spaces:

  PROPERTIES
  {
    Target=PlanningRoutingLine(Table 99000830);
  }

then try to convert again, and it works. But since the PlanningRoutingLine is not the real name in BC, then it cannot find the reference, then you will get error in VS Code.

Hope it helps to narrow down the search, @atoader

[ALGitHubBot]

The fix for this issue has been checked in to the master branch. It will be available in the bcinsider.azurecr.io/bcsandbox-master Docker image starting from platform build number 36485.

If you don’t have access to these images you need to become part of the Ready2Go program: aka.ms/readytogo

For more details on code branches and docker images please read: https://blogs.msdn.microsoft.com/nav/2018/05/03/al-developer-previews-multiple-releases-and-github/ https://blogs.msdn.microsoft.com/freddyk/2018/04/16/which-docker-image-is-the-right-for-you/

[alapenas]

Version 15.0.36560.0-w1 from bcsandbox-master has the same issue "illegal character in Path"

[qutreson]

Note that the fix was done for the 14.x version. As this is the last version that contains C/SIDE (in order to export the txt file), this is also where our focus will be when fixing bugs or improving the txt2al. We will fix our online documentation to mention it.

[ralf-escher]

Successfully converted the example above with Convert-ModifiedObjectsToAl and the -runTxt2AlInContainer parameter with a newer BC14 sandbox [14.6.36666.0-de-ltsc2019], like mentioned in #5309 by @freddydk

Filename: tableextension50105.TableExt-_Planning Routing Line_.al

tableextension 50105 tableextension50105 extends "Planning Routing Line"
{
    fields
    {
        field(5043040; "Belongs to Operation No."; Code[10])
        {
            Caption = 'Belongs to Operation No.';
        }
    }
}

@qutreson: is the resulting AL file correct? As I started the migration two months ago, the name of the extension was named after the original object (see below), now it is simply {type}{id}

tableextension 50105 "Planning Routing Line" extends "Planning Routing Line"
{...}

[ralf-escher]

Related issue: the generated .xlf language files correspond to these extension names (e.g. tableextension50105). If we reorganize/rename the extension files (e.g. by @waldo1001 CRS AL Language Extension), the caption could no longer be found since the <trans-unit id> is calculated (somehow) by the extension name.

<trans-unit id="TableExtension 3470817506 - Field 1644257177 - Property 2879900210" size-unit="char" translate="yes" xml:space="preserve">
  <source>Belongs to Operation No.</source>
  <target>Gehört zu Arbeitsgangnr.</target>
  <note from="Developer" annotates="general" priority="2"></note>
  <note from="Xliff Generator" annotates="general" priority="3">TableExtension tableextension50105 - Field Belongs to Operation No. - Property Caption</note>
</trans-unit>

[qutreson]

@ralf-escher we are currently escaping invalid characters by using _ but as discussed in the related issue, we will fix it to just remove invalid characters.

The fix did not modify the name of the AL objects created by the txt2al in these files, it is still {type}{id}.

After the conversion to AL, by modifying the name of the AL objects, you are breaking the translation keys. This is by design. As you mentioned it, the translation key is based (among others) on the name of the application object.

When renaming application objects, you need to update your translation files to contain the new key for the object. To help you in that task, you can have a look at the note in the xliff which gives a human readable version of the key. (TableExtension tableextension50105 - Field Belongs to Operation No. - Property Caption).