Al: What is the LineStart Property and why is Compare-NAVApplicationObject and Txt2Al complaining about it.

[GreatScott000]

Use BC October Release

I have a 2017 based customization. I want to make it an extension in BC. I have imported the 2017 "base" objects and customized objects into new, empty, BC1810 databases. I have then used the Export-NAVApplicationObject -ExportToNewSyntax function to export the objects from each database and then run the compare. There are 200 modified objects in the customized database. When I run the Compare-NAVApplicationObject - ExportToNewSyntax it reports there are 2950 changed objects. Nearly all of them only different because of the [LineStart(##)] attribute being different.

What is the [LineStart(##)] attribute? Of what use is it to me?
Compare-NAVApplicationObject generates a delta for each file where there is a difference in [LineStart(##)]. Why does it matter to the Compare function?

Txt2Al throws

Warning: Unsupported feature: Property Modification (Attributes) on [procedure name]

for each [LineStart(##)]. Why does it matter?

Is there a way to turn this off? Am I missing something? If I am not using the exported objects for anything can I just remove that attribute from the source?

[kalberes]

That is used by the AL debugger in VsCode. The code exported to new syntax is an internal state, that cannot be used for anything else but converting C/AL to AL, or generating symbols. Thus anything it contains is also 'internal'.
LineStart is an attribute like that. This is how the debugger will know where to find code if you step into base app code (C/AL). Also go to definition is also relying on this to find your C/AL based method correctly.
If you just want to diff, you can remove them.

[GreatScott000]

Okay, how do I stop the 25k+ instances where Compare-NAVApplicationObject finds that [LineStart(##)] does not match due to custom code I am trying to convert to an app?

Thank you for the explanation.

[kalberes]

But why are you doing diffs on the exporttonewsyntax format? isn't the standard format good enough to do a diff? ExportToNewSyntax just prepares the standard C/AL output format for better digestion by txt2al and symbolgeneration.

[GreatScott000]

Per this article The Txt2Al Conversion Tool it says to use the -ExportToNewsyntax. If don’t you use it you get a number of other problems like object ids instead of object names in variable declarations.

[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 25722.

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/

[Pieterheinevdm]

the txt2al.exe of the latest bcinsider ("version": "14.0.26992.0" bcinsider.azurecr.io/bcsandbox-master:w1-ltsc2019) still cannot handle LineStart differences in delta files. Could you please change the txt2al.exe so it skips these LineStart PropertyModifications?

example:
{ PropertyModification;
Target=OnBeforeCodeInsertInvLineFromShptLine(PROCEDURE 15);
Property=Attributes;
OriginalValue=[[Integration]][LineStart(352)]]];
ModifiedValue=[[Integration]][LineStart(363)]]] }