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 ..
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:
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.
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 ;-).
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 …
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.. .
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 ;-).
it doesn’t work if you have changed to much in your file, then the add and delete stays even in the staged files.
Yeah, that’s why I said to start a new branch before you start to rename..
thanks for the information you saved me a lot of work, but at use your steps i found one mistake on “CRS.ObjectNamePrefix”: “Prefix “:
When i rename all files, this functionality rename the pageextensions .. etc … group(“Prefix”) to group(“Prefix Prefix”). So at this point i do it using rename all on Notepad++.
Thanks in advance again,
Yeah – that’s probably because of the ” “, right? If you disregard the space, I get other issues .. so that’s why I decided to keep it as is .. sorry :(.
The new naming scheme MS recommends is atrocious. You’re better off disabling the warning.
Why? It’s automatically .. and don’t have to think about it. Why would I disable the warning while I can comply without any effort :-/
Renaming of the files itself works perfectly.
But all the references to the files are not changed.
You mentioned you changed +6000 files in a day.
How do you do this with the references?
I didn’t succeed in using the “rename symbol” in this functionality. After many tries, I finally gave up .. so yes .. that’s not gonna work.
Though – we did quite some tricks with default Find/Replace (with regex) where we were able to do the renames pretty fast and efficient..