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:

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:

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": "..al",
"CRS.FileNamePatternExtensions": "..al",
"CRS.FileNamePatternPageCustomizations": "..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.  

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:

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”

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

And “Discard All x Files”

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):

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.

A drag&drop to a new folder as well.

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