Follow-up of post:

New bulk replacing VSCode extension - Dynamics 365 Business Central Community

In this previous post  we talked about the extension Custom diagnostics, bulk replacements and configurable fixes - Visual Studio Marketplace, that allows to set replacements, to apply over and over the same replacements without writing the regular expressions to apply again. This tool helped us to convert lots of old C/SIDE software to new extension AL code. First we use the Txt2AL standard tool and then I apply some saved replacement rules from this extension to remove all conversion errors in all workspace files with a single command.

(Fun fact: this extension has 27 versions…..and 20 downloads).

But this extension has some additional tools to boost AL edition in VSCode:

Diagnostics and Fixes.

Diagnostics

When editing in VSCode we can see below the Problems Panel:

In this problem panel you can see compilation errors, warnings, information or hints. These diagnostics came from inside the language definition, it is written in stone, and we needed to set new ones easily to not to always pay attention to avoid repetitive errors not detected by standard language definition.

Custom diagnostics

With “Custom diagnostics” extension new diagnostics can be easily settled following these steps:

https://marketplace.visualstudio.com/items?itemName=JessAlmarazMartin.customdiagnostics#:~:text=in%20all%20documents.-,Diagnostics,-In%20the%20same

Tech with good use cases is useless. So let´s see what we can do with this tool.

Use case 1. Beware of too-sort code fields

I wanted to detect when I created a new code field “No.” with length 10 instead of 20. This is very problematic, because if you do not notice and upload the program to the app source, you cannot change this if this field is in the primary key.

Usually the fields ending with “No.” in its name must be a 20-length code type. So, we settled this diagnostic:

So, if I create this field I get this diagnostic in Problem panel:

Use case 2. SQLType Variant

Another problem could be the property SQL type if it is Variant. OnPrem is available, but you can not publish a cloud extension if a field has this SQL type. Nobody warns to remove this before app publishing in a Cloud environment. To detect this problem, we created this diagnostic rule:

Use case 3. Layout path

When we convert a report from C/SIDE with Txt2AL layout path is set to workspace root path:

Is a chaos having the paths this way, because when you build the package next time, all new report layouts will be created in the app root path. If you want to keep a clean file structure you must set the layout report path to src/report/layout path as bellow:

We made a rule to avoid this, raising an error in the panel if the report layout path is out of this folder:

Notice that we place a condition to exclude from the panel if it already has /layout/ in the line:

Reminder

Finally, if you want that all these diagnostics work, you must include them in a “diagnosticset” this way:

And configure the diagnosticset in extension settings:

Custom fixes

Next post I will break down the fixes part of my extension.