How to REALLY rename all AL-files of your Business Central app..

You remember this post?  I tried to warn you that when v16 comes out, there will be a new code rule that will check your filenames – and you’ll have to (if you don’t disable it) comply with the file name convention of Microsoft.  If you don’t automate your file naming, then you’re in for some .. uhm .. challenges.  I just made sure that the automation of the filenames complied with Microsoft’s rules .. .

I need to correct my store in that post though.  I had been working on this “RenameWithGit” setting, which didn’t work with multiroot workspaces and had some other stability problems.  Only after my post – thanks to a reaction from James Pearson on twitter – I learned there is a much simpler way to do this.

First of all …

Forget about the “RenameWithGit” setting

Indeed – just forget I ever built it.  I’m actually thinking of taking it away in the near future.  I already removed it from all my workspaces, and I strongly recommend you to do the same.  It doesn’t work like it’s supposed to work .. and I’m embarrassed enough about it ;-).

There is only one word you need to remember ..

Staging!

All you have to do after you renamed all objects is to stage the changes.  That’s it.  And then you’ll see that actually everything is just fine.. .  I found some kind of description about this ability here: https://stackoverflow.com/questions/29706086/how-to-stage-a-rename-without-subsequent-edits-in-git. 

If you’d rename a file, you will get a delete and a new untracked file in Git, like you can see here:

When you stage the file in vscode, you get the rename:

What it actually does in a stage is it will compare the files, and when more than 50% is the same, it will indicate it as a “rename” it in stead of deleting the old name, and creating a new file.  That’s smart!

And yes, indeed .. I have been immensely wasting my time on the “RenameWithGit” setting :(.

Can I make sure everyone always stages before commit?

Well .. It’s actually good practice to always “intentionally” stage.  You must have seen this message already:

In VSCode, it’s called “smartcommit”.  But honestly, in my opinion, the smartest commit is an intentional commit.  I don’t like this message, and I switch it off by setting this up in my user settings:

“git.suggestSmartCommit”: false

I’m not forcing you to do so .. but this way, you can easily check in VSCode if the rename of the file,  was actually a rename of the file – and not deleted and new files.  Like it was intended. 

So, what is now the safest workflow to rename my files?

Quite the same as I mentioned in my previous post about this – but a bit different. 

1. Create a new branch

 Yep, I still recommend to do the entire process in a separate branch.  Of course.  It will give you a way out if you messed up ;-).

2. Change the setup

The setup is actually very similar as in my previous post, only now with the “RenameWithGit” = false.  To match the file name convention of Microsoft .. this is what I would use:

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

Alternatively, you could add the “RemovePrefixFromFilename” or “RemoveSuffixFromFilename” – but make sure you set up the mandatoryAffixes-setting in the AppSourceCop.json as well, for the CodeCop to accept the removal of the prefix or suffix.

3. Commit

This commit is there because you might want to revert after a failed rename-attempt.

4. Rename all

This is the same “Rename All” function I talked about in my previous post:

It will rename all files of the current active workspace (the active workspace is the workspace of the currently activated document (file)) – not all workspaces.  So you probably have to do this for all workspaces separately.  Thanks to the “RenameWithGit” to false, I expect no mistakes.  I was able to apply this to +6000 files today .. so it’s tested, I guess ;-).

5. Stage

This is THE step I was talking about earlier.  Here you can check if the rename was successful – all renamed files  should indicate an “R”, like:

When you see that – you’re good to go and …

6. Commit

Just commit, push and create a pullrequest to the necessary branch .. and you should be done!

Wait .. So I can do this in a multiroot workspace as well?

Yes indeed – this flow does work in a multiroot workspace.  Do execute it for all workspaces separately though, like mentioned before.  That’s how I implemented it.. . 

Conclusion

It’s a piece of cake.  Really.  So just do it, comply with the naming convention, and don’t feel like you’re cheating on Microsoft ;-).