15. PURE-02 If you can’t use just PowerShell, use .net, external commands or COM objects, in that order of preference
First, at the end of the day, get the job done the best way you can. Utilize whatever means you have at your disposal, and focus on the techniques you already know, because you’ll spend less time coding that way.
That said, there are advantages to sticking with “PowerShell native.” In general, folks tend to prefer that you accomplish tasks using the following, in order of preference:
-
PowerShell cmdlets, functions, and other “native” elements. These are (or can be) very well documented right within the shell itself, can (and should) use consistent naming and operation, and are generally more discoverable and easier to understand by someone else.
-
NET Framework classes, methods, properties, and so on. While not documented in-shell, they at least stay “inside the boundaries” of .NET, and .NET Framework classes are typically well-documented online.
-
External commands, like Cacls.exe or PathPing.exe. While not documented in-shell, most tools do offer help displays, and most (especially ones that ship with the OS or server product) have numerous online examples.
-
COM objects. These are rarely well-documented, making them harder for someone else to research and understand. They do not always work flawlessly in PowerShell, as they must be used through .NET’s Interop layer, which isn’t 100% perfect.
