What the solution checker does and why you should use it

Quality is never an accident. It is always the result of intelligent effort. John Ruskin

The solution checker is a free tool to help developers verify their code doesn’t contain many bad practices and code smells.  I recommend developers incorporate into your development life cycle to help you keep your code quality high.  This post will explain what is, why use it and some common errors.

How does the solution checker work?

You can find out what the solution checker is and instructions on how to run in the post Use solution checker to validate your model-driven apps in Power Apps

The solution checker runs static analysis on your

• Plugins – C#
• Custom Workflows – C#
• Web resources – JavaScript and HTML

The static analysis will find common problems in your code and suggest you fix them.  This is like code analysers such as FX Cop, Resharper or Code analysis rule set reference.

I like static analysis because it was a code review on my code before I submitted it for a review.  You can set the rules to automatically run and it helps you create higher quality code.

The other benefit was it would highlight problems and suggest best practices that I hadn’t heard of, I would read up about the rule and suggestion to see if I wanted to use it.

You can run the solution checker on a solution and it will check all your code, identify issues and give documents on how to solve it.

How do you use it?

You need to enable the solution checker and then you can trigger it manually in the Power Apps maker portal.  Go to solutions, select the solution and then you can right click or click the run solution checker button on the top.

The solution checker could take a few minutes to run, depending on how big your solution is.

You kick off the solution checker and then it creates a report that you can either view online or download as an Excel file.

Go through the warnings and fix the problems.

There is a PowerShell module which would allow you to automatically run the solution checker in your DevOps build, this enables you to make sure your code is clean.  Read Get started using the Microsoft  Power App checker PowerShell

There is another way to use it my using the XRM Toolbox plugin by Jonas Rapp, you can find more information and full tutorial – Power Apps Checker for XrmToolBox. It has the bonus of applying different rule sets

Why would you use it?

You should have the mindset of all code and customisation don’t work until they are proven to work, until you have tested them.  Assume the quality of your code is low until you prove it to be high by testing it with static analysis and/or a code review.

The best moment to sovle a bug is when you are writing the code and testing it yourself.  At this moment you know the most about the solution and will be able to fix it quickly and make changes before other code is dependent on it.

When writing code it’s better to spend more time doing it right and less time fixing it later #HoskCodeWisdom

The initial goal of an IT project is to turn the requirements into customisations and a solution the business can use to do their job.  This is the short-term goal, the long-term goal is to create a solution easy to maintain and the most effective way to do that is to create high quality, well-structured customisations.

The creation of a customisation is a quick part, the maintenance and extension of a customisation last for years.  If you don’t create quality code, the customisations become complex and maintaining, extending and debugging will take longer.

The solution checker helps you find your bad code and suggest how to fix it.  A good tool to improve the quality of your coding and raise the standard of your code.

Microsoft offer free code reviews for projects which quality for Fast Track assistance (250 seat plus), it’s a good idea to run the solution checker to proactively fix the warning that would appear when Microsoft do a code review.

The solution checker doesn’t run the same rules as a Microsoft code review, but the solution checker is a minimum check and a subset.  More information about FastTrack for CE projects can be found – FastTrack customer success service and with big projects it will be there, so you should learn to align with it.

Some common warnings and explanations

The section below will cover some common warnings I have found with the solution checker.  I will explain what they mean and what you should do to fix those problems.  The solution checker gives some text and links but sometimes these are not obvious and take some interpretation.

Event registration not enabled

An event registration entry was detected on the form form name on the entity account for the event Form.onload that is disabled. Consider enabling or removing the function name

This error occurs because you have an event on OnLoad or OnSave that is disabled.  You should delete the event because it’s not running.  It’s bad practice to leave customisations disabled or inactive because they confuse people and can easily be enabled accidently or on purpose.  A disabled or deactivated customisation can be enabled and then you have a new bug which is very difficult to identify.

Use strict equality operators

For most comparisons the strict equality comparison algorithm is the right choice as it will return the expected results. The strict operators handle null and undefined values as expected.

This error means we should not use == but use the strict ===

The reason is JavaScript lets you compare different variable types but this can have unexpected results, so by using the strict ===  it compares the same type and won’t have unexpected results

this gets a warning

entity.field == “Line1”

this is good

entity.field === “Line1”

Learn more here

Use strict mode when possible

Strict mode is a way to introduce better error-checking into your code. Code should run in strict mode wherever possible. This is a JavaScript warning.

Add use strict to the JavaScript file, this link explains it more detail

According to this article it Strict mode helps :

• It catches some common coding bloopers, throwing exceptions.
• It prevents, or throws errors, when relatively “unsafe” actions are taken (such as gaining access to the global object).
• It disables features that are confusing or poorly thought out.

Should you use single or double quotes e.g.

‘use strict’;

or

“use strict”;

In JavaScript, it doesn’t matter if you use single or double quotes, here for more details

To invoke use strict for the whole file, place it before any other JavaScript statements.  It’s possible to apply use strict for specific functions.

Read more – web-use-strict-mode

Do not ship debug helper code in production source

Remove debugger and console statements and it’s lazy and don’t do it, they are found in JavaScript files

Remove these

• debugger
• console.error(“Error: “ + message)
• console.log(“field updated”)

Xrm.Page

‘Xrm.Page’ references or accesses a deprecated API in the client context object model. Replace this call with the following client context API: ‘ExecutionContext.getFormContext’

Xrm.Page is depreciated and will not work in October 2020 release, DO NOT WRITE THIS CODE, get into the habit now.  There is no excuse because it’s been well publicised and there are lots of examples of using the new syntax.

Xrm.Utility.alertDialog(this.statusText)

This highlights a depreciated Xrm call.  Xrm.Utility.alertDialog(this.statusText)’ uses a deprecated API in the client object model.  You should Replace this call with the following client object model API: ‘Xrm.Navigation.openAlertDialog’

Replace Xrm.Utility.alertDialog with Xrm.Navigation.openAlertDialog

il-specify-column

This warning will be thrown for Plug-in or workflow activites and its about selecting all columns not specifict columns

Avoid selecting all columns via Common Data Service query APIs.

example

new Microsoft.Xrm.Sdk.Query.ColumnSet(1)

Evaluate the use of AllColumns in ColumnSet constructor call with ‘true’ argument.

Don’t select all columns in your queries, select only the fields you need.  It will make your code faster and easier to understand.

Async JavaScript

var requestXhr = new XMLHttpRequest(); // Explicitly setting the async parameter to false or supplying a variable with a value of false will force this as a synchronous

call.requestXhr.open(‘GET’, ‘/test/test.txt’, false);req.open(“GET”, globalContext.getClientUrl() + “/api/data/v9.1/opportunities?$select=status&$filter=opportunityid eq” + “ “ + OpportunityID, false)

Read an explanation of this error Interact with HTTP and HTTPS resources asynchronously

You can have a query which does an OData query to retrieve data from another entity but best practice is to set this as Async, the warning comes when you this query is synchronous and slows the form load.

Create quality

The solution checker is minimum standards you should aim for, you should be aiming higher.  The bigger the project the more important it is to keep the quality high.  Enterprise projects create a lot of customisations and code, so you want to put in steps to ensure what is created is quality, otherwise you will have a huge mess on your hands quickly. There are lots of problems on an enterprise project and reducing your problems by having quality code will help you focus on them.

Other suggestions

Embrace DevOps and automate your builds and releases.  This speeds up the feedback loop, reduces manual mistakes and takes the boredom out of development.

Unit test your code will shorten the feedback loop, help the developers write better code and have reusable tests you can run to see has broken the build.  It helps find bugs now and when you change the code.

Create standards and best practices and make people stick to these.  The best way is to run static code analysers and have code reviews.  Code reviews are a great motivator for people to write higher quality code (because they know their code will be reviewed) and a good way to teach developers to write good code by having someone explain changes.

Use TypeScript instead of JavaScript.  I like TypeScript because it’s strongly typed and more like C# and this means you create better quality and more standard code.  JavaScript is a powerful scripting language but it makes it easy to write poor quality code which is hard to maintain.

Make quality and not speed your priority.  Taking shortcuts and doing things fast doesn’t save you time in the long term, all it does it kick the problems down the road and they hit you later when time is more limited and the long-term effects of poor code is to slow down the project and increase the difficulty of maintaining the code.  In the same way you don’t want a builder to take short cuts building your house, you don’t want developers to take shortcuts creating code and customisations on a project.

Start today to create better quality customisations and be a great software engineer because no one ever got into trouble for creating high quality code.

Advertisement