en-us/about_scriptcop_fixers.help.txt
|
Several of the problems that ScriptCop uncovers can be fixed automatically.
It's possible to write "Fixers", small bits of code that can repair issues. Like Rules, Fixers are an extensible part of ScriptCop Fixers have a much simpler structure: A fixer should be either a function or a script named like Repair-* and containing only the following 4 parameters: param( # The Rule that flagged the problem [Parameter(Mandatory=$true,ValueFromPipelineByPropertyName=$true)] [ValidateScript({ if ($_ -isnot [Management.Automation.CommandInfo] -and $_ -isnot [Management.Automation.PSModuleInfo] ) { throw 'Must be a CommandInfo or a PSModuleInfo' } return $true })] [PSObject]$Rule, # The Problem [Parameter(Mandatory=$true,ValueFromPipelineByPropertyName=$true)] [Management.Automation.ErrorRecord] $Problem, # The Item with the Problem [Parameter(Mandatory=$true,ValueFromPipelineByPropertyName=$true)] [ValidateScript({ if ($_ -isnot [Management.Automation.CommandInfo] -and $_ -isnot [Management.Automation.PSModuleInfo] ) { throw 'Must be a CommandInfo or a PSModuleInfo' } return $true })] [PSObject]$ItemWithProblem, [Switch]$NonInteractive ) If you'll notice, three of these parameters map to the three pieces of information you get when you run Test-Command. The fourth parameter, -NonInteractive, is passed down from Repair-Command. If -NotInteractive is passed, your fixer should not interact with the user in any way. If is it not, a fixer is free to interact with a user. This allows you to write a fixer to get information you could not possibly know automatically (like getting a description of what the command does) If the fixer doesn't know what to do with the problem, it should ignore it. Fixers should identify errors by an ErrorID, which is a property on $Problem. In this way, multiple specific errors from a rule can be handled by the same fixer. Where as Rules simply need to report errors, fixers need to provide a little more information. Since Fixers need to provide this information in a consistent way, they use 2 private functions to do the trick: CouldNotFixProblem and TriedToFixProblem There are three different outcomes from a fixer: | The problem could not be identified | Do Nothing | | The problem cannot be fixed | return CouldNotFixProblem $ErrorID | | The fixer tried to fix the problem | return TriedToFixProblem $ErrorID | |