How that is being done, is described in multiple places. Let me just reference to this post on my blog to get you going on it :-).
Since that post, there is somewhat more possible. And probably, the way of converting it, will change in the future, as this is all “work in progress”. A good way to keep track of what Microsoft is doing about this AL language, is following their blog.
You’ll see that in the June-update, you are able to also convert Delta-files. This is great – I was hoping for that, because I’m involved in some apps, that I’d like to be able to convert them.
Last week on Friday, it was “Conversion day”. The day we would switch to AL development for one of our apps. And I ran into issues because of my own stupid ignorance – which I’d like to share (I’m one of those guys that shares how stupid he can be …)
Thing is – it’s not my first day I’m working with Deltas. I have been working with deltas for quite some time, and even, I included that in my way of working – backing up a certain development with PowerShell, which was going to convert a bunch of stuff to a certain folder, which is being put to github. A standard way of doing it. I have an example online with “WaldoNAVPad”. You can see the folder structure. Basically, I generate everything that I can – deltas, txt, fob, reverse deltas, … .
I also just noticed that I already shared HOW i’m doing that here. A very simple function that is going to backup my developments.
Everything comes together
I already have all I need, right?
- I have Deltas of all my apps in source controll
- Microsoft has a conversion tool
I can just execute this conversion tool for the deltas I already have
Because there is one important and therefor critical element that should not be forgotton: You can’t convert the “ususal” text objects – you need the text objects in – what Microsoft calls it – the “New Syntax” (hate the name, by the way).
And that applies to deltas as well. You can’t just create deltas from “classic” textfiles – no – if you want to convert deltas, you need to create text files first in the NewSyntax. Both Original and Modified!
Good news, you can do that with the updated PowerShell CmdLet: Export-NAVApplicationObject that comes with NAV. Just use the switch “ExportToNewSyntax” and there you go!.
Let me briefly show you the differences between a “classic” export and an export with the “NewSyntax” flag by showing you some screenshots from my mergetool.
Here you see that dates, times, and booleans are represented differently .. and even references to fields, where there are no double quotes around them in the classic export. Though, it needs it in al, so the “ExportToNewSyntex” foresees them:
And what about this:
Where you get the actual object names in stead of references to the object type and object id. This will make your code in AL much more readable!
Friday, this one was causing me most headaches:
Because we had gigantic calcformulas where also the double quotes were missing – you would need to solved all this manually in al. Just imagine you have calcformulas like:
Bottom line: don’t forget to export to New Syntax, like I did! 😉
Can you import “NewSyntax” txt objects?
That would be nice, wouldn’t it? We would just be able to completely move to the new syntax in our source control. Well .. Think again. You can’t. The date formats and such are simply not supported, as shown in this error message when trying to import such a txt file:
If you’re using my modules (if not, shame on you! :p), you might want to update them, because I have included this “NewSyntax” in some of my functions. Now, with the Backup-NAVApplicationObjects, you have the option to “include the New Syntax” as well.