Chapter 17. Extending your reach with .NET
This chapter covers:
I love it when a plan comes together!
Col. John “Hannibal” Smith, The A-Team
When we started the design work on PowerShell, our focus was almost exclusively on cmdlets. The plan was to have lots of cmdlets and everything would be done through them. Unfortunately, as Robert Burns observed, “The best laid plans of mice and men often go awry,” and we found that we didn’t have the resources to get all the required cmdlets completed in time. Without these cmdlets, we wouldn’t have adequate coverage for all of our core scenarios. How to solve this, we asked? “Let’s just depend on .NET,” was the answer. We decided to make it easier to work directly with the .NET Framework. That way, although it might not be as easy to do everything the way we wanted, at least it would be possible.
In retrospect, this may have been one of the best things to happen to PowerShell. Not only did we backfill our original scenarios, but the set of problem domains (such as creating graphical user interfaces) in which we found PowerShell to be applicable greatly exceeded our original expectations.
In this chapter, we’ll show you how to effectively apply the .NET Framework to extend the reach of your scripts. We’ll also look at some considerations in Power-Shell’s support for .NET and how they might lead to problems.