Analyzing the first results of Application Checker for MsDyn365FO

I recently checked out what results we are getting from Application Checker for Microsoft Dynamics 365 for Finance and Operation (which is available in 10.0.3 PU27) for our extension models. Within the next months the Application Checker will get more attention because at some point in time Microsoft will not allow to deploy packages which have rule violations in Application Checker. The set of rules is published on GitHub and you can (try) to contribute: https://github.com/microsoft/Dynamics365FO-AppChecker

Before you can use the Application Checker you have to install BaseX which is described here: https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/dev-tools/install-basex?tabs=admin After the successful installation you can use the Application Checker checkbox in the build dialog within Visual Studio to run the corresponding checks. After the compile you can find the violations the compile errors/warnings window is you can so in the following illustration:

Es wurde kein Alt-Text für dieses Bild angegeben.

In our case the Application Checker found the following rule violations in our models/packages:

  • Recursion detected: I think this rule do not make sense because a modern programming language it should be possible to use recursions. The argument for banning recursions is “…we had recursion related problems in production environments to often…”. For me this is also no agreement for putting the recursions on a “black list”. I think it would make more sense to add runtime checks to restrict the recursion depth.
  • Reflection calls: This piece of code was not on my radar anymore. It has been developed in the early stages of the extension model to get the value of protected variables. So this piece of code can simply go away to get rid of the violation.
  • References to hard coded string type: This piece of code is also legacy and can simply be changed to get rid of the violation.
  • Method complexity is above 30: This rule tries to identify big monolithic methods like the ones from the WHS mobile menu items. In our case the identified problem was also from a WHS mobile menu item which has a very high refactoring effort.

So my conclusion is that for us the effort to meet the application checker rules is in acceptable range.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s