What Solution Checker checks, and what it doesn’t
Solution Checker is free, Microsoft-built, and good at the job it was designed for. That job is narrower than most people realise, and the gap has a specific shape worth knowing.
Every Dynamics developer has run Solution Checker. It is free, it ships in the maker portal and the PAC CLI, and it catches real problems. If you are not running it, run it.
It also gets asked to do a job it was never built for, usually by someone troubleshooting production rather than authoring a solution. Knowing where the boundary sits saves you from expecting an answer the tool cannot give.
What Solution Checker actually does
Solution Checker is static analysis over the contents of a solution. You point it at one, it runs a Microsoft-maintained rule catalogue across the plugin assemblies, the JavaScript web resources, and the solution metadata, and it returns severity-tagged violations against those rules.
Three properties of that design matter more than any individual rule:
- It runs at authoring time, against a solution, usually at or near publish.
- Its unit of analysis is one component measured against one rule. Does this plugin use a deprecated API. Does this script call
eval. Does this metadata follow the pattern. - Its audience is whoever is building the solution, and its output is a list of things to fix before shipping.
For that job it works well, and nothing below is an argument against using it.
The question it is not built for
Open Solution Checker and ask it what writes to account.creditlimit.
There is no answer, and not because of a missing rule. The question spans a plugin here, a classic workflow there, a modern flow in a different solution entirely, and forty lines of form JavaScript that nobody has opened in three years. Answering it means holding every component in one model and querying across them. Solution Checker analyses components one at a time against a rule, which is a different shape of tool.
Solution Checker asks whether each component is well built. It does not ask what the components do to each other.
That difference explains most of the confusion. Both tools read plugin assemblies. Both read form scripts. Solution Checker reads them to score the code; a dependency graph reads them to extract which columns get written. Same source bytes, different question, and the outputs do not substitute for each other.
Dev time and run time
| Solution Checker | Environment-wide dependency analysis |
|---|---|
| Runs at authoring time, at or near publish | Runs against a deployed environment, on demand |
| Scoped to one solution | Scoped to the whole environment, across every solution |
| One component measured against one rule | Every component held in one model and queried across |
| Written for whoever is building the solution | Written for whoever is troubleshooting production |
| Output is a list of violations to fix before shipping | Output is an answer to a question about what is already deployed |
Adjacent categories, different buyer moments. The developer about to publish and the admin staring at a field that changed overnight are not the same person, even when they are the same person.
Where there is no overlap at all
The security side is the cleanest boundary, and the reason is structural rather than a matter of rule coverage.
Solution Checker analyses what is inside a solution. Role assignments are not inside a solution. Which user holds which security role, which team a service account belongs to, which business unit a role is scoped against: all of that is environment state, and none of it travels in a solution file. There is nothing there for a solution analyser to read.
So questions of this shape sit entirely outside its remit:
- Which security roles are assigned to both human users and integration accounts
- Whether a disabled account still holds role assignments or record shares
- What a given integration account can actually reach once teams and business units resolve
- Which roles grant privileges nobody appears to need
This is not a gap Microsoft could close by adding rules. A tool that reads solutions cannot report on state that solutions do not contain. Answering these means reading the environment, which is a different kind of tool with a different deployment story.
What Solution Checker does that Pathix does not
This part matters more than the rest of the page, because it is where the two tools stop being comparable at all.
Solution Checker owns code quality, and Pathix deliberately stays out of it. Pathix will not tell you that a plugin calls RetrieveMultiple inside a loop, that a script uses a deprecated Xrm.Page accessor, that a component will break on the next platform version, or that a solution is ready for AppSource certification. Those are real problems, Solution Checker finds them, Microsoft maintains the rules, and duplicating that would be a worse version of something free.
Pathix does report a small set of structural conditions that read as code quality: a plugin step writing a column its own trigger filters on, a synchronous step making an outbound call inside the save transaction, an update step registered with no filtering attributes. Those are in scope because they are visible in the dependency graph and they cause the incidents forensics gets called for. They are not an attempt at a lint catalogue, and the catalogue is not where the two tools compete.
The comparison not to make
Counting rules on either side is the wrong measure. A tool with more rules than Solution Checker would just be a second linter, and you do not need one. The useful question is whether you have a way to answer questions that span components, because that is the thing neither Solution Checker nor the platform's own dependency tracking will do for you.
Which to reach for
Reach for Solution Checker when you are about to ship. Is this solution well built, does it use anything deprecated, will it survive the next platform update, is it fit to publish.
Reach for environment-wide dependency analysis when something is already deployed and the question is about behaviour rather than quality. What writes this column. What breaks if I change it. Who can reach this data. What did last Thursday's release actually alter.
Most teams need both, and the overlap between them is small enough that running one is not an argument against the other.
Why the platform's own dependency check has the same boundary →