Chapter 25. Wrapping up the .NET Framework
As you start exploring the edges of what PowerShell can do, you’ll run across instances where there’s no command built that will do what you need done. In many instances, you may discover something lurking in the massive .NET Framework that can do what you need (or perhaps it’s an external command, an old COM object, or something else). Is it okay to use that raw .NET stuff in your scripts?
Well, no. But also, yes.
Let’s go back to the base reason PowerShell exists. Microsoft Windows, as an operating system, is and always has been chock-full of things to help make automation possible. It’s an operating system, after all, running on a computer, and computers are all about doing things automatically. The problem with Windows is, and always has been, that those automation things are friendly to professional software developers and not so friendly to administrators who may lack deep programming experience (or lack the time to do deep programming).
You’ve always been able to automate the heck out of Windows if you happened to know—and had time to code in—C++, C#, and the other first-class languages that were built to talk to Windows’ application programming interfaces (APIs). The problems started only if you didn’t know, or didn’t have time to code in, those lower-level languages or to learn those APIs.