Why and how to rename all AL-files of your app with the “CRS AL Language Extension”

First of all, this is my first post of this new year, so I’d like to take this opportunity to wish you all the best and happiness for 2020! Last year, I did a post on my new hobby “3D Printing”. Well, now we’re a year later, I’m still printing almost full time 24/7, so let me wish you all the best with some 3D Printed goodies I did for Xmas ;-).

So now – “let’s get started” with ..

Why would I rename all my AL-files?

Well – because of Microsoft and their new (upcoming) code analysis rule about file name conventions.  You might already have complied with their previous conventions, and … they will change.  Even better: they actually already changed .. Just read here:

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/compliance/apptest-bestpracticesforalcode

In the “old” days, Microsoft wanted you to name the files including the object numbers.  But not anymore.

This doesn’t really have to be a problem .. because today, we can freely choose however we want to name our files.

But that will change (a bit) …

If you use the insider version of the AL Language Extension for VSCode, you’ll see that we will get new code analysis rules that check the file name. This is an example that I had with my waldo.restapp I recently blogged about:

PROBLEMS @ 
OUTPUT DEBUG CONSOLE 
v AL JSONHe1percod.a1 src @ 
TERMINAL 
A The file JSONHelper.Cod.al has an incorrect name. The valid name is JSONHelperWLD.Codeunital. AL(AA0215) [1, 16] 
v AL RESTBlob.Taba1 src @ 
A The file RESTBlob.Tab.al has an incorrect name. The valid name is RESTBlobWLD.Tableal. AL(AA0215) [1, 131 
v AL RESTHe1percod.a1 src @ 
A The file RESTHelper.Cod.al has an incorrect name. The valid name is RESTHelperWLD.Codeunital. AL(AA0215) [1, 16] 
v AL RESTLog.Ta1xal src @ 
A The file RESTLog.Tab.al has an incorrect name. The valid name is RESTLogWLD.Tableal. AL(AA0215) [1, 13] 
v AL RESTLogcard.Paga1 src @

It doesn’t matter what my previous naming convention was – the result is that all of a sudden, te compiler is going to have an opinion about it and will identify it as a “problem”.  It even calls it “incorrect”, not just “not following the guidelines” or whatever.. ;-).

Why would I care?

Well, if you don’t care .. then don’t!  Just put rule AA0215 in your custom coderules and move on with your life ;-).

But I care.  I want to comply with as many coderules .. as long as they don’t “hurt” me or my company.  That’s why we have a simple step in the build pipelines of our company: if any coderule would fail with an error or warning – the code is not accepted by the build.  And admittedly – this is a good naming convention, anyway.  So .. let’s comply!

Waldo’s CRS AL Language Extension

As you might know – I created a VSCode Extension that makes it possible to easily handle file naming conventions.  Because of these new guidelines (and coderules), I recently added a new option “ObjectTypeShortPascalCase” so that now it’s also possible to handle it the correct way with settings in this extension. 

BUT

Don’t rename your files by just invoking the command “Rename All Files” – DON’T:

>rename al 
Rename - All Files 
CRS: 
recently used

Because:

  • You might change all your code history
  • You might have wrong settings
  • You might not be able to rollback and rethink ..

So, let me try to give you the safest way for you to rename all your files

I’m going to assume you are source-controlling your code here.  If not .. I don’t even want to talk to you ;-). 

Just kidding – if not, just quickly initialize a git repo from the current state of your code.  You might want to revert all changes you did .. and this gives you a way to do that.  Honestly, this particular rename I did for this blog, I did 3 times .. just saying ;-).

1 – Create a new branch

Before you do any coding, you should branch out.  Same with this: just create your own snapshot of changes to work in.  You can’t be too careful ..

You created it?  Well, now you’re safe.  Any kind of mistake within the next steps – just remove the branch, create a new one, and start fumbling again ;-).

2 – Change the setup

I think this is a good setup for the new filename conventions:

    "CRS.FileNamePattern": "<ObjectNameShort>.<ObjectTypeShortPascalCase>.al",
    "CRS.FileNamePatternExtensions": "<ObjectNameShort>.<ObjectTypeShortPascalCase>.al",
    "CRS.FileNamePatternPageCustomizations": "<ObjectNameShort>.<ObjectTypeShortPascalCase>.al",
    "CRS.OnSaveAlFileAction": "Rename",
    "CRS.RenameWithGit": true,
    "CRS.ObjectNameSuffix": " WLD",

Notice that there is no property “RemoveSuffixFromFilename” or “RemovePrefixFromFilename”.  These properties invoke an extra procedure after renaming, to make sure you have no prefix in the filename anymore.  Thing is – it would make the name not comply again with the naming convention of Microsoft’s coderule, unfortunately.

3 – No Multiroot

Also notice the “renamewithgit” setting.  This is important, but a difficult one.  If you don’t set this to “true”, any rename would result in a “delete” and “create” of your file – meaning you would lose all the history of your files.

In my world of DevOps and Source Control, this is unacceptable.  Really unacceptable.  I want my history kept at all times!  So, this setting is going to make sure you rename with git (“git mv”).

Now – in all honesty – I have spent too much time already to make this setting as stable as at all possible. And it still isn’t.  Sometimes, it just doesn’t do what it’s supposed to do.  Known issues are still:

  • new files in combination with a multiroot workspace, it acts crazy (just deletes the content)
  • With the “rename all”, it seems to be too fast sometimes, which fails the rename, which loses the history, which makes me angry ;-).

For the first, I have built in some fail saves, which basically will NOT rename with git of you have a multiroot workspace (not my preferred option, but for now, I have to give up on this – spent too much time already :'( ) ..

And the second – that’s why I write this blogpost ;-).  How can you still rename all your files successfully, even when it would fail on your first attempt.

But – to solve the first (you DO want to “renamewithgit”), just avoid using multiroot workspaces.  If you have multiple workspaces open, just close VSCode, and open that workspace of that one app you would like to rename all files from.

4 – Commit these settings!

You might want to revert to this very version of this set of files when any of the next steps would fail for some reason or another.  So please, commit now!

5 – Rename – All Files

Now is the time to start renaming all your files.  

>rena alll 
CRS: Rename - All Files 
recently used

Remember you set the “renamewithgit”, AND you’re not working multiroot, so it is going to try to rename all with git.  Indeed: try!  Because more than likely, “some” will succeed, and “some” will fail.  If you have failed ones, it will show the “crs-al-language” output like this:

PROBLEMS @ 
28/11/2819 13:1e. 
28/11/2819 13:1e. 
28/11/2819 13:1e. 
13:1e. 
13:1e. 
13:1e. 
13:1e. 
13:1e. 
13:1e. 
DEBUG CONSOLE 
TERMINAL 
crs-al-language 
Rename all files 
warning 
* fatal: Unable to create .git/index.lock• : 
File exists. 
Another git process seems to be running in this repository, e.g. 
an editor opened by •git commit' . Please make sure all processes 
are terminated then try again. If it still fails, a git process 
may have crashed in this repository earlier: 
remove the 
28/11/2819 
28/11/2819 
28/11/2819 
28/11/2819 
28/11/2819 
28/11/2819 
28/11/2819 
file manually to continue. 
* fallback: renaming without git from RESTB10b.Tab.a1 to RESTB10b. Table. al 
* you might want to set the setting "crs.RenameWithGit" to false for this workspace. 
success: git mv 
success: git mv 
warning 
* fatal: Unable 
JSONHe1per 
RESTHe1per 
to create 
. Cod . al JSOM4e1per. Codeunit.al 
. Cod.al RESTHe1per. Codeunit.al 
•c: /_Source/C 0 8 files out of 21 was renamed

It seems that one process is blocking another to execute decently .. and because of that, it is actually going to rename the classic way, which would mean, it doesn’t preserve your git history.

When the complete rename is done, you should also have a look at the Source Control pane.  If you have fail-messages, you should get some files in “Staged Changes” and some in “Changes”

v STAGED CHANGES 
ÎȘI 
AL 
AL 
AL 
AL 
AL 
AL 
AL 
AL 
AL 
AL 
AL 
JSONHelper.Codeunit.al Src 
RESTHelper.Codeunit.al Src 
RESTLogcard.Pageal Src 
ShowRequestMessageMethCodeunit.al Src 
ShowResponseMessageMeth.Codeunital Src 
Src 
RESTBlobTableal Sr, 
Src 
RESTLog.Table.al Src 
RESTLogListPage.al Sr,

Well: Staged are fine, and the ones in “Changes”, you’ll need to retry.  Do this by “Discard All Changes”

sa6ueqo p.e.s!a 
utuu103 opun 
pau6.s) pa6as uwwoo 
(puawv) pa6as uwwoo 
pa6as uwwoo 
pau6!s) uwwoo 
(puawv) uwwoo 
IM uunuoo 
mqoueJ8 qs!łqnd 
inmaqo 
qsnd 
qsnd 
lind 
(aseqau) lind

And “Discard All x Files”

Visual Studio Code 
There are 3 untracked files which will be DELETED FROM DISK if discarded. 
This is IRREVERSIBLE, your current working set will be FOREVER LOST. 
Cancel

Now, you basically only renamed the ones that were able to rename, and you staged them. The ones that failed are restored to their original state, which still has all history, but are not renamed. So ..

6 – Repeat …

it’s obvious .. this is where you repeat.  So, rename again, and discard the changes if you have failed ones.  And keep doing that, until all files ended up in your staged area (the “R” in the back indicates that you renamed the file):

v STAGED CHANGES 
AL 
AL 
AL 
AL 
AL 
AL 
AL 
AL 
JSONHelperCodeunit.al Src 
RESTBlobTableal Sr, 
RESTHelper.Codeunit.al Src 
RESTLog.Table.al Src 
RESTLogcard.Pageal Src 
RESTLogListPage.al Sr, 
ShowRequestMessageMethCodeunit.al Src 
ShowResponseMessageMeth.Codeunital Src

7 – Commit, PullRequest …

And this means: you’re done.  Time to commit and pullrequest your changes to your master/release/dev.. .

Conclusion

I’m not proud of this workaround – I’d like to see it “just” work.  But when it comes to “renaming or moving files with git”, there seems something odd.  I mean, think about it – a simple rename in the VSCode Explorer window also ends up with a “Delete/Untracked”, meaning – you lose history.

v CHANGES 
AL RESTHelperWLD.codeunital Src 
AL 
RESTHelperWLD.codeunit2.al Src

A drag&drop to a new folder as well.

AL JSONHelperWLD.Codeunital Src 
AL JSONHelperWLD.Codeunital Src\test

So – just my conclusion – if the VSCode wizards are not able to solve this simple “rename” issue – why would I be able to do it better than I already did ;-).

If this is useful to you! It was for me 😉

5.00 avg. rating (98% score) - 3 votes

Permanent link to this article: https://www.waldo.be/2020/01/09/why-and-how-to-rename-all-al-files-of-your-app-with-the-crs-al-language-extension/

16 comments

10 pings

Skip to comment form

    • Achim on January 9, 2020 at 8:28 am
    • Reply

    “CRS.FileNamePattern”: “..al”,

    Looks like you forgot the actual pattern.

      • waldo on January 9, 2020 at 8:57 am
        Author

      Thanks! Those bloody html conversions :-/

    • Achim on January 9, 2020 at 8:41 am
    • Reply

    Microsofts’ recommendation is to remove the prefix and spaces, the extension preserves spaces and doesn’t remove a prefix by default.

      • waldo on January 9, 2020 at 8:59 am
        Author

      You have an example and reference? Because that’s not what I got from the compiler :-/

      • Achim on January 9, 2020 at 9:43 am

      Well, it happened once. Can’t reproduce it now.

      • waldo on January 9, 2020 at 10:33 am
        Author

      I’m going to look into the “MandatoryAffixes” setting some more. And I might have to do some more changes because of it. Thanks for the heads up.

      In the meantime, if you have any (reproducable) issues, you are always welcome to report them here: https://github.com/waldo1001/crs-al-language-extension/issues/

    • NathanNyme on January 9, 2020 at 9:43 am
    • Reply

    > “Also notice the “renamewithgit” setting. This is important, but a difficult one. If you don’t set this to “true”, any rename would result in a “delete” and “create” of your file – meaning you would lose all the history of your files.”

    My attempts says a slightly different thing:
    When you rename a file without git, it sees a D and a U, but when you stage both, they merge into a R.
    This occurs only into both files share at least 50% of code.

      • waldo on January 9, 2020 at 11:57 am
        Author

      Yeah, I got the same remark on Twitter – thanks for this. I will probably rethink the entire solution and write an update-post .. . Meanwhile, this will work 😉

      • NathanNyme on January 9, 2020 at 12:25 pm

      Later and with more coffee inside: Oh, and Sorry for my bad english! And thanks for all your shares and work for community !

      And happy new year 🙂

      • waldo on January 9, 2020 at 12:45 pm
        Author

      Thanks so much 🙂

    • Kristof on January 27, 2020 at 4:06 pm
    • Reply

    Renaming time here as well… worked “out of the box” as stated in github and here in the comment.

    Still I have a couple of files that did not rename. (well according to the log they did:
    27.1.2020 15.49.40 – Rename file from Pag50438.Pool.al to Pag50438.Pool.al )

    Unfortunately CRS Extensions is not telling the reason for this. When I try to reorganize it even loses track of the folder and dumps the file in the App root folder. Any Idea what could cause this? Some bad character?! It happened on Pages and Codeunits… also closing everything down and running again did not resolve the problem.

      • waldo on January 27, 2020 at 4:12 pm
        Author

      Did you retry to rename just one of those files? Is that a repeating bug on the same files? If so, to debug, I’ll need such a file, I’m afraid :-/. No idea why this happens.. .

      • Kristof on January 28, 2020 at 8:52 am

      Just checked with an (your favorite) AL:GO – moved one of the files in it – checked CRS settings – executed Reorganize all and got this:

      28.1.2020 08.47.35 – Reorganize all files
      28.1.2020 08.47.36 – Rename file from HelloWorld.al to CustomerListExt.PageExt.al
      28.1.2020 08.47.36 – Rename file from Pag50438.Pool.al to Pag50438.Pool.al

      I can mail you the file if you want – so you can check yourself. I assume for the rename the file must not be compile-able 🙂

      • waldo on January 31, 2020 at 5:37 pm
        Author

      Seems to be an encoding issue – I mailed you 😉

    • Gregory on March 2, 2020 at 5:15 pm
    • Reply

    Hello Eric, tested you workaround and it doesn’t work for me.
    When I rename a file with CRS.RenameWithGit=true, history doesn’t save in local and remote repo, but I see R in Stages.
    When I rename a file with CRS.RenameWithGit=false, history saved in local and didn’t save in remote repo. I see D and U in changes, when I stage both, they merge into R.
    After commit , I push my changes to remote repo an all history disappear in both cases.
    I tested command Rename Current file.

      • waldo on March 2, 2020 at 5:19 pm
        Author

      Hi Gregory,

      sorry it didn’t work, but indeed, the “Staging”-approach is actually the one where I wasn’t aware of at the time I was writing this post. Glad you figured it out ;-).

  1. […] Source : Waldo’s Blog Read more… […]

  2. […] recently blogged about how to rename files with my VSCode Extension to comply with the new filename conventions from […]

  3. […] recently blogged about how to rename files with my VSCode Extension to comply with the new filename conventions from […]

  4. […] recently blogged about how to rename files with my VSCode Extension to comply with the new filename conventions from […]

  5. […] you have used the CRS Language Extension in the past, I strongly recommend that you read this blog post by Waldo. Due to new naming conventions from Microsoft, there will be stricter rules for naming in the […]

  6. […] you have used the CRS Language Extension in the past, I strongly recommend that you read this blog post by Waldo. Due to new naming conventions from Microsoft, there will be stricter rules for naming in the […]

  7. […] remember this post?  I tried to warn you that when v16 comes out, there will be a new code rule that will check […]

  8. […] remember this post?  I tried to warn you that when v16 comes out, there will be a new code rule that will check […]

  9. […] remember this post?  I tried to warn you that when v16 comes out, there will be a new code rule that will check […]

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.