Power Platform Community Forum Thread Details

Hello Community,

I am using the Microsoft.PowerApps.Checker.PowerShell module to understand Solution Checker rulesets and rules so that I can apply rule-level overrides correctly when running static analysis.

My goal is to:

Discover available rulesets
Inspect which rules belong to a given ruleset
Override specific rules using New-PowerAppsCheckerRuleLevelOverride
Execute Solution Checker via Invoke-PowerAppsChecker

However, I am facing consistent runtime issues with the discovery cmdlets.

Observed Issues

Ruleset discovery fails

Results in:

This occurs for all geographies (Asia, Europe, US, etc.).

Rule discovery is unusable

Results in:

Parameter set cannot be resolved

AmbiguousParameterSet

Environment Details

Windows PowerShell 5.1
Module: Microsoft.PowerApps.Checker.PowerShell v1.0.52
Newtonsoft.Json v10.x resolved
Authentication successful via Add-PowerAppsAccount
Invoke-PowerAppsChecker works correctly and generates reports

Understanding So Far

The module documentation states these cmdlets are pre-release
It appears the Power Platform backend API has changed
The PowerShell module may no longer align with the current service contract
Checker execution still works, but metadata discovery does not

Questions

Should developers rely instead on:

Checker output inspection (JSON/SARIF)?
PAC CLI?
Documentation only?

I am able to run Solution Checker and apply rule overrides, but the lack of a working discovery mechanism makes it difficult to manage rules programmatically.

Any guidance on the current supported approach would be greatly appreciated.

Thank you.

Are Get-PowerAppsCheckerRulesets and Get-PowerAppsCheckerRules still supported and expected to work?
Is this a known issue caused by backend changes?
What is the official/recommended way to:
- Identify which rules are applied by a ruleset?
- Determine valid Rule IDs for use with New-PowerAppsCheckerRuleLevelOverride?

Categories:

Experimental features

Power Apps Pro Dev & ISV

Hi @CU21110542-0,

First step:

Microsoft.PowerApps.Checker.PowerShell module is up to date by running:
Update-Module -Name Microsoft.PowerApps.Checker.PowerShell

Second Step:

Let’s analyze the first error. System.ArrayTypeMismatchException is a run-time error while executing with Get-PowerAppsCheckerRulesets -Geography Asia, is a known issue likely caused by a bug or version mismatch in the PowerShell module or its API responses
An initial workaround is to omit the -Geography parameter. So give it a clean run w/o parameter like this:
Get-PowerAppsCheckerRulesets
Sometimes, this returns available rulesets and avoids the error. So instead of writing this:
$rulesets = Get-PowerAppsCheckerRulesets -Geography Europe
Write this:
$rulesets = Get-PowerAppsCheckerRulesets

The excerpt is taken from here, it suggest specifying -Geography is helpful but for our case to narrow down the issue we can avoid that, by avoiding are using default United States preview region.

Example Without Geography Parameter:
$rulesets = Get-PowerAppsCheckerRulesets
$rulesets | Format-Table -Property Name, Description
This will list available rulesets without triggering the array type mismatch error.

Let’s analyze the second error:
“Parameter set cannot be resolved AmbiguousParameterSet” error is being confronted when required parameters are missing or conflicting parameters are inputted, causing PowerShell to be unsure which parameter set to use.

The -RulesetName parameter is helpful when calling Get-PowerAppsCheckerRules. This cmdlet requires a ruleset name to list rules within that ruleset. The syntax is: Get-PowerAppsCheckerRules -RulesetName "<RulesetName>"
Get-PowerAppsCheckerRules -RulesetName "Default"

Please note that, if you don’t know the ruleset name beforehand, first try to use
Get-PowerAppsCheckerRulesets without -Geography parameter and pickup the ruleset name and use in Get-PowerAppsCheckerRules api.

We have completed our analysis. If you see error is still there, we have to find alternative, I suspect pre-release modules might cause something usuaual.

Pre-release justification:

It seems, your understanding is correct. The Microsoft.PowerApps.Checker.PowerShell module is still in pre-release, and the backend Power Platform API has evolved, causing metadata discovery cmdlets like Get-PowerAppsCheckerRulesets and Get-PowerAppsCheckerRules to fail or behave inconsistently. Meanwhile, Invoke-PowerAppsChecker continues to work for running static analysis and generating reports.

//--Here is an example of complete workflow

# List available rulesets
$rulesets = Get-PowerAppsCheckerRulesets
$rulesets | Format-Table -Property Name, Description

# Select a ruleset name from the list
$rulesetName = "Default"

# Get rules in the selected ruleset
$rules = Get-PowerAppsCheckerRules -RulesetName $rulesetName
$rules | Format-Table -Property RuleId, Description, Severity

# Use a RuleId from the output to create an override
$override = New-PowerAppsCheckerRuleLevelOverride -RuleId "<RuleId>" -Severity "Warning" -IsEnabled $false

# Run Solution Checker with the override
Invoke-PowerAppsChecker -SolutionPath "<PathToSolutionZip>" -RuleLevelOverrides @($override)

//-- The above approach confirms you identify valid Rule IDs programmatically and apply overrides correctly when running static analysis.

Recommendation:

Let's use Get-PowerAppsCheckerRulesets to list available rulesets.
Let's use Get-PowerAppsCheckerRules -RulesetName <RulesetName> to retrieve all rules within a ruleset.
The o/p includes valid Rule IDs, can be used with New-PowerAppsCheckerRuleLevelOverride for applying overrides.

Pre-release items are not very stable to use in production unless you have community references. I believe the problem you are facing should be common problem for all if not route is well known.

Final Notes:

Right now, these cmdlets are in pre-release mode and may have runtime issues due to backend API changes.
If discovery cmdlets fail, we can inspect the JSON/SARIF O/P generated by Invoke-PowerAppsChecker for Rule IDs and metadata.
As a second option, we can use the Power Platform CLI (pac solution check) which may provide more stable metadata discovery.

I am sure some clues I tried to give. If these clues help to resolve the issue brought you by here, please don't forget to check the box Does this answer your question? At the same time, I am pretty sure you have liked the response!