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 ..
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:
“old” days, Microsoft wanted you to name the files including the
object numbers. But not anymore.
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) …
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:
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.. ;-).
you don’t care .. then don’t! Just
put rule AA0215 in your custom coderules and move on with your life ;-).
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!
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.
rename your files by just invoking the command “Rename All 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 ;-).
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 ..
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 ;-).
I think this is a good setup for the new filename conventions:
"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.
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:
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 :'( ) ..
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
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.
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!
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.
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
Well: Staged are fine, and the ones in
“Changes”, you’ll need to retry.
Do this by “Discard All Changes”
“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 ..
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):
means: you’re done. Time to commit and pullrequest
your changes to your master/release/dev.. .
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.
drag&drop to a new folder as well.
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
If this is useful to you! It was for me