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:
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.
Don’t rename your files by just invoking the command “Rename All Files” – DON’T:
- 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.
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.. .
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 😉
Looks like you forgot the actual pattern.
Thanks! Those bloody html conversions :-/
Microsofts’ recommendation is to remove the prefix and spaces, the extension preserves spaces and doesn’t remove a prefix by default.
You have an example and reference? Because that’s not what I got from the compiler :-/
Well, it happened once. Can’t reproduce it now.
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/
> “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.
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 😉
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 🙂
Thanks so much 🙂
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.
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.. .
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 🙂
Seems to be an encoding issue – I mailed you 😉
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.
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 ;-).