Repository navigation
Rule request: AvoidNewObjectCmdlet #2046
Description
Activity
You might also consider to link this type of rules to the
#Requires -Version x.xstatement.
(In case it doesn't exist in the concerned script: simply suppress the warning.)Reacted by Sam ErdeAgree with it, feel free to contribute a rule for it :-)
Agree with it, feel free to contribute a rule for it :-)
Might that be a PowerShell based rule? (FYI: I don't have enough C# known to write something like that in C#)
Agree with it, feel free to contribute a rule for it :-)
Might that be a PowerShell based rule? (FYI: I don't have enough C# known to write something like that in C#)
To be included with PSScriptAnalyzer, it would be C# because PowerShell based ones are too slow and CPU intensive to run by default for the millions of PSSA users. Alternatively you could write your custom PowerShell rule and open source it for the community to use.
I needed this as well! Put together #2109 and is ready for review 😄
Dr. Skill Issue (@DrSkillIssue),
Thank you for picking this up!
I was about to write a rule in PowerShell but wasn't ably to do more than just some preparation before my holidays last 2 weeks.
As this rule requires you to resolve the existence af a specific parameter which I needed to be able to do before and I (incorrectly) did in e.g. myAvoidDynamicVariables.psm1rule. Therefore I decided to ask the specific question: How to resolve command name and parameters from a CommandAst.
And apparently I didn't do this very well as there is indeed a good method that can do this for you, thanks to Santiago Squarzon's helpful answer
My C# skills are very poor, but I quickly tried to understand your code and I believe you don't use thisbindcommandmethod either which I think would be better to use for this knowing that the-ComObjectmight be (0) positioned or provided elastically, like:New-Object -Com InternetExplorer.Application.iRon7 Oh! I didn't know that existed. I'll definitely use this for future rules. However, StaticParameterBinder wouldn't be of use for Parameter Splats as you still have to search for what keys are within said Parameter Splat. In other words, unfortunately wouldn't make the code easier to understand as you still have to hunt for variables.
You are correct that I missed Parameter abbreviations. I'll readjust the logic for that. Good catch as I'm always typing out full parameter names and that slipped my mind.
Reacted by iRon7- added a commit that references this issue
on Jun 10, 2026
The
New-Objectcmdlet is basically* legacy.Since PowerShell V3.0 (12 years ago), PowerShell supports type accelerators which perform much better, see: PowerShell scripting performance considerations / object creation.
*) Exceptions left there (e.g. with the use of the
[-ComObject] <String>parameter)Therefore I think that it makes sense to have a
AvoidNewObjectCmdletrule.related: Avoid New-Object Hashtable
#60