If one needs to read more on PowerShell under the hood, for example how powershell interact with the .NET framework where can we start?
You know, I get asked this question a lot, and I’m glad you asked it again because it made me really think about it. I’ve started to think, over the years, that .NET Framework has – for a lot of PowerShell users – become some kind of magical mystery tour. If only you can figure it out, it’ll be great! And folks probably look around and wonder why, 12 years after PowerShell as first released, there still aren’t any “.NET Framework for PowerShell” books out there!
So let’s do some level-setting.
.NET Framework isn’t a language. It’s a set of libraries, which basically means it’s a whole caboodle of functionality. It’s a toolbox. You don’t “code in .NET.”
A variety of different languages are able to easily access the tools in the .NET Framework toolbox. Visual Basic and C# are perhaps the most well-known, and PowerShell is certainly one of them, although it’s less capable than “first class” languages (in that there are some advanced things .NET is capable of that PowerShell can’t deal with).
“Interacting” with .NET from PowerShell is trivially easy: you use New-Object to create a new instance of whatever .NET class you want. You then use that instance’s properties and methods to do whatever it is that class does. That’s it. Lesson over.
Ah, but the next question is, “well, what classes are there and how do I use them?” Well, start at https://docs.microsoft.com/en-us/dotnet/framework/ and Good Bloody Luck to you because .NET contains north of 50,000 classes, and that’s just the base stuff. You can add more.
There’s no magical shortcut to learning 50,000 things. .NET makes it a little easier by grouping them into hierarchical namespaces. So, the System.Data “section” contains all the stuff having to do with accessing databases and whatnot. But it’s freaking huge. This is why .NET developers get paid a good bit of money – they have to know all this stuff. Most of them pick it up while learning C# or Visual Basic, since those languages by themselves aren’t very useful. As you’re learning C#, you’re basically starting to learn .NET as well.
And I can’t stress enough how big .NET is. It’s got whole sections that have their own names, like Windows Presentation Framework (WPF), Language-Integrated Query (LINQ), and tons more. Some of these are massively complex, as if your toolbox contained not only hammers and wrenches but also small fusion reactors. .NET Framework is designed for building serious multi-tier applications across a dozen or more different delivery modalities. You don’t take a class on .NET; you spend half your life taking classes. It took me a week to learn WPF, half a week to learn LINQ (the first flavor; there are like a dozen, now), and another week just to understand how C# and Visual Basic each handle object inheritance. .NET isn’t friendly; it’s designed for hardcore software development.
Fun fact: prior to 2006, approximately zero administrators would ever have thought of using .NET to accomplish anything. Like, if .NET contains a class called System.Medical.Cures.Cancer, no administrator would have thought to touch it.
But in 2006, PowerShell happened.
Literally the whole point of PowerShell was to take all that enormous complexity, filter it down to stuff an administrator might care about, and wrap it in something a lot friendlier and easier to learn. With PowerShell, you can call up a Buch of instances of System.Diagnostics.Process without having to understand anything about variable typing, constructor methods, callbacks, asynchronous methods, enumerable collections, or any of that. You just run Get-Process. But if you’re going to start “interacting” with .NET directly, even via PowerShell, then you’ve got to worry about the same things a C# developer would have to worry about. Life is going to be exponentially more complex for you. And in some ways, you’re worse off than a C# developer, because you’ve still got PowerShell sitting in the middle trying to “simplify” things. So you can easily go down rabbit holes that a C# developer would never encounter.
In 2018, .NET is still the same enormous, unfriendly, complex, gigantic, huge framework that it was in 2006 (well, it’s way bigger now). If no administrator would touch it back in 2006, why are people so eager now? Well, perhaps because PowerShell made .NET more accessible. That is, easier to get to, not easier to learn. But just because it’s easier to get to doesn’t mean it’s going to be easier to learn.
My advice – and this is, incidentally, far from a universal belief that everyone agrees with – is to stick with PowerShell for PowerShell. If you’ve got a task that can only be performed in “real” .NET, haul out a copy of Visual Studio and write a cmdlet in C# or Visual Basic. You can then use that cmdlet in PowerShell, and thats’ exactly the pattern PowerShell itself was built around: write cmdlets to “hide” all the .NET stuff. .NET development is far easier in Visual Studio (the ‘real’ one, not VS Code), and you can output a cmdlet that’s e-z to use in PowerShell. Again, plenty of people will disagree loudly with me on this, but most of those people are experienced C# developers who are deeply comfortable using .NET already, and so they don’t mind banging out .NET stuff in PowerShell.
Yeah, there’s some simple stuff you can do in .NET. [System.Math]::Abs(-5) is easy, right? Sure. But it’s not like there’s a list of “100 things an administrator can do in .NET that won’t make your eyes bleed.” Filtering down a toolbox of 50,000+ things to just the stuff “you might need” on a given day isn’t possible.
OK, Don, shut up and just plug the book, which is where this was always going to end up, right? <grin> Head to https://leanpub.com/powershell-scripting-toolmaking and buy it. In it, Jeff and I use .NET quite a bit, including for stuff like database access, which actually is one of the simpler things you can do. We’ve a chapter on using .NET, or at least how to comprehend the documentation in a way that makes sense to PowerShell people. Just make sure you’ve got good expectations: .NET is big and difficult. There’s no way to change that, but the book can at least let you put your pinky in the door.
(Anyone with additional resources are welcome to drop a comment, especially if you’re a non-developer who found something that helped you get over the .NET learning cliff.)