Pre- or Suffixing
It’s been known for a while: pre-or suffixing is necessary to “live in the cloud”. It prevents duplicate names in various places: duplicate table names, duplicate field names .. things like that. It is actually very well described on Microsoft Docs here: https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/compliance/apptest-prefix-suffix.
In short: you need to pre-or suffix, especially for apps on AppSource, but actually on anything you do!
AppSourceCop can help (let’s say “force”) you
You are probably familiar with : the codecop with code analysis rules that are specifically for AppSource. Well .. when you enable this, it can help you. And in the next release: it will force you to remember to set an affix (which means: a suffix or a prefix).
You can simply enable the AppSourceCop by:
In terms of “affixes”, the AppSourceCop needs to know which you use. If you don’t do that – in the next release (v16) – the analyzer will tell you that you HAVE to tell him:
What you need to do
From the documentation, it’s quite clear what you need to do:
- Create a file AppSourceCop.json in the root of your workspace (next to the app.json)
- Fill it with the property “MandatoryAffixes”, and provide all affixes that you intend to use in the app. Here is an example of the content of that file:
You’ll see that IntelliSense will help you to complete this file… . As you can see, I also provided the supported countries as also that will be mandatory (by a coderule) in release 16. But let’s focus on the affixes in this post ;-). What I told the AppSourceCop in this case, is that I will use only one affix, being “WLD”.
Well, you’re not done yet. All you’ve done now, is told the AppSourceCop on which affixes it needs to check the objects and controls. That way, it can “remind” you that you need to pay attention to it, like here:
Obviously, it’s your job now to take this into account, and haven decent names for your objects, fields, .. .
Wait .. it’s not going to provide that affix for me??
No! But don’t worry – that’s where I come in ;-). You might be familiar with my “CRS AL Language Extension” in VSCode that can handle renames of files. Well, during the rename, it can provide a prefix or suffix. So by simply setting some extra settings for my extension (and yes – by providing the suffix again), you’ll be able to get this going for you in an automated way:
In short, this setting will automatically provide the WLD-suffix where it needs to when you save a file.
There is a disconnect though …
The AppSourceCop allows multiple affixes .. and my CRS AL Language Extension does not. So whenever you intend to use multiple affixes, I’m afraid you’ll have to disable the automatic rename by my extension, because it will only apply one. Simply remove the settings about the suffix, and provide it manually (AppSourceCop will remind you where ;-)).
Even more – if you enable the CodeCop in the next release, you’ll even have another rule to worry about: file name conventions. So, if you enable codecop:
This is something you could get in v16:
I actually already blogged about that very recently, so I’m not going to repeat that. BUT – this coderule is also going to assume than when you used this “MandatoryAffixes” (which you have to in the next release), that you DON’T use the affix in the filename (read the error above carefully, and you’ll notice it doesn’t want my affix in it).
Well, I had foreseen this setting for it:
But that also is only useful for only one suffix or prefix at this moment.
In short – auto renaming can become a challenge … :-/ … and that sucks…
Headaches that I intend to solve for you in the near future. This is what I intend to do in short term:
- I’m going to read and take the “MandatoryAffixes” setting from the AppSourceCop.json file into account
- When you have enabled “RemoveSuffixFromFilename”, I will loop all affixes, and remove it when it’s used as prefix or suffix. The danger there is that I’ll remove too much, or make the wrong assumptions, so I’ll make it case sensitive, and probably stop removing after I find one affix – just to minimize the risk. Future will tell how well it works. But this will hopefully solve the fact that the CodeCop wants us to disregard a multitude of affixes.
- I will keep the “ObjectNameSuffix” and “ObjectNamePrefix” setting. It will act as a “current” setting. Meaning that when I find that one of the affixes in the AppSourceCop.json is already applied, I’m not going to apply anything anymore. If not, I’ll apply the one from the settings.. . I’ll try to make this case sensitive as well.
Or that’s at least how I have it in my head now … . I also realise that simplicity is key – I shouldn’t make it too complicated to use this. So .. yeah .. this did give me quite some headaches already ;-). So, if you have any idea, feedback, tip, … please share ;-). I’m open for all ideas.