Where PowerShell confuses me, .NET !

Hi all,

This is something which has confused me some what. When you read best practice with PowerShell the recommendation is to only use .NET when there is no other option. I’ve read a few things recently, for example, from the brilliant Jeff Hicks and powershell magazine.

This stuff really fascinates me, but i don’t understand how to learn or know what .NET classes to use. How do others know what to do ? My goal is to become really good at PowerShell and i’m investing lots of times with books by the greats Don Jones and Jeff Hicks (Learn powershell and toolmaking, in depth, deep dives) and the pluralsight videos by Jeff Hicks.

There does seem to be a call for .NET in a fair few examples.

You definitely do have to resort to .NET from time to time - but there’s no “way” to learn it. .NET Framework is huge, with tens of thousands of classes. Most of us “learn” through Google. I mean, if you told me that you wanted me to use a .NET class to connect to an FTP server - well, I don’t even know for a fact if it’s possible, but it might be, so I’d just start Googling and see what I found.

But the reason we always say “use .NET as a last resort” is precisely because it’s harder to learn. There’s no help built into PowerShell, and really, you’re not using PowerShell anymore. You’re writing a little C# script in the PowerShell language, and it can definitely be technically more complicated. Yeah, you have to do it sometimes, and whenever I do, it’s always an adventure of figuring it out. I don’t think there’s any way to shortcut that.

Books and training on .NET are invariably intertwined with language, so it’s difficult to find .NET training that isn’t also C# or VB training, which won’t necessarily help you use .NET in PowerShell. So… I just kind of use the MSDN documentation and muddle along as best I can.

@Don, correct me if I’m wrong, but Powershell cmdlets are written in .NET (C# or VB.NET). As Powershell has become more popular\prominent, OEMs and vendors have begun creating entire foundations on Powershell such as Microsoft, Citrix, VMWare, etc. so that administration extends beyond a GUI interface. Additionally, new Powershell versions introduce new cmdlets, so much in fact that through a couple of iterations standard cmdlets went from hundreds to thousands and I’m sure within the next couple versions ten of thousands. If you add 3rd party modules, the need to reference .NET directly will diminish drastically as developers build technologies on top of Powershell.

OK, thanks Don. That does kind of help. I read the stuff you and Jeff do and its like, “Wow” these guys know all sorts ! But what you’ve just said makes me feel a little better ! :slight_smile:

Graham,

This is one of those few cases when I disagree with Don over “best practice”.

I would never recommend that one only use .Net as a last resort in PowerShell, because to me, that’s a nonsense statement. PowerShell is a .Net language. Everything in PowerShell is a .Net object, from your variables to your script to the host itself. Everything you do in PowerShell is .Net. Doing something in .Net is doing it in native PowerShell.

To not leverage the capabilities of the .Net objects you are already holding in the palms of you script whenever doing so is easier, faster, or more functional than using a cmdlet is just silly.

“Learning .Net” is like “learning literature.” You don’t learn literature, you learn to read, and then you go read a lot and write a lot. To “learn .Net”, you need to understand the basic structure of a .Net object, and then you Google a lot, and experiment with lots objects.

Tim, I think you’ve missed my point entirely. I never said not to use .NET, which is what you’re implying.

PowerShell - in the form of cmdlets - is much easier for someone who’s a newcomer to explore, discover, and figure out. It’s a surface specifically intended for administration. If there was value in simply having a “.NET Scripting Language,” that’s what Jeffrey Snover and Microsoft would have invented, and they wouldn’t have bothered with cmdlets. But “raw” .NET carries a substantially higher learning curve, and so “pure” PowerShell offers an easier point of entry.

To not leverage the capabilities of the .Net objects you are already holding in the palms of you script whenever doing so is easier, faster, or more functional than using a cmdlet is just silly.

And in cases where .NET is easier, faster, or more functional, then it might well be appropriate. I’ve never said not to use it. For me, “last resort” means, “the only way to get the job done.” Now, if the job needs more speed, and .NET is faster, then that’s the “last resort.” But I wouldn’t use .NET simply because it seemed faster, if faster wasn’t a part of the job need. So perhaps it’s a matter of perspective, but calling it “nonsense” without taking a moment to ask about the perspective is somewhat insulting.

And Rob, you’re completely correct. Microsoft has an explicit goal of reducing the amount of raw .NET an admin needs to work with - so clearly, the company also agrees that .NET isn’t 100% perfect for every possible situation. Again, if they thought that, we wouldn’t have cmdlets. If .NET was perfect for every scenario, we’d all just use C#.

The point of PowerShell is its relative ease of use for newcomers, and it’s more admin-focused use patterns. That doesn’t mean .NET is bad. It means it can be harder to learn, and that it isn’t as explicitly well-suited for administration. .NET is wonderful at other things, and it’s great that PowerShell lets us leverage “raw” .NET when need arises. But the reason I refer to it as “last resort” is simple: because .NET is harder to learn and less admin-specific, whatever you create in it will be harder for someone else (who isn’t a developer) to maintain and expand upon. The more you can stick with “pure” PowerShell (while still getting the job done), the more your work will be accessible to others.

Scripters are typically horrible at following best practices like source control, coding standards, and the like. Using “pure” PowerShell helps to mitigate some of those poor practices. Start “scripting” entirely in .NET and you quickly get something that’s exceedingly hard to maintain and leverage.

Yes, use “pure” .NET when it’s the right tool for the job. However, as much as possible, stick with PowerShell constructs and cmdlets when they will get the job done, because you’ll be leveraging what is essentially the whole point of PowerShell. I’ve never said to “ignore” .NET - I’ve said that, if you can get the job done with PowerShell cmdlets and functions, do that by preference.

Of course, that’s just my opinion based on my experiences. But I want to make sure you understand why I have that opinion, so you can evaluate it within your own context and decide if it also makes sense for you.

Don, i spend alot of time reading books, articles and videos by yourself and Jeff Hicks. I’m new to Powershell, 3 months in of good learning time, and i’m enjoying it. I have great respect for you and Jeff and value your knowledge on the subject greatly. I’ve seen a few articles by Jeff on Petri where he used .NET commands. I was curious and wanted to know what part that could play for me in my learning and developing. I can see that there is a part to play, but not necessarily a big part. I want to be strong in PowerShell and be well rounded with other parts, like .NET. So your comments and advice have been helpful in my learning path. I’ve played a bit with the Visual Basic .NET to get a click and popup box for work colleagues to use. I was wondering how far to take this .NET learning, but as you said, its last resort, and knowing if i can do most with PowerShell and dip into .NET if required is good enough for me :slight_smile:

Ah, good. A vigorous debate on a topic that deserves to be debated.

Don, I agree with you almost completely. I do not mean to imply that you believe the complementary opposite of what I am saying. Working with .Net is not a beginner topic. If one has a good cmdlet for what one needs to do, one should of course use it.

What I have a problem with is the false dichotomy that gets embedded in the minds of new PowerShell users between “native” PowerShell and .Net. Too often they end up thinking that they can and should avoid learning and using .Net for as long and as often as possible, that “native” PowerShell techniques are inherently better than .Net techniques with no regard for context.

A beginner should be made aware that all of the objects they work with in PowerShell are .Net objects. They should know that even though it is an advanced topic that they aren’t ready for in depth, the entire .Net framework is available in PowerShell for them to leverage in their scripts. When they are given a beginning exercise in which they write something like If ( $File.LastWriteTime -lt (Get-Date).AddDays(-30) ), it should be pointed out that they are using .Net object properties and methods.

A user who is ready to make the leap from beginner to more advanced scripter should know that the single simplest thing to learn that will most advance their scriptwriting is a basic but solid understanding of .Net objects. If they understand namespaces, classes, static classes, enumerators, properties, fields, methods, constructors and events, they will understand everything they are working with better. Once they have that basic understanding and some experience Googling for useful classes and their technical details, the door to everything in .Net, which is essentially everything Microsoft and more, opens up to them.

A basic understanding of .Net even leads to better “native” PowerShell. If someone understands what a constructor is, and knows that New-Object works by calling a constructor of a class, they can look at the MSDN article on the constructors for their class to find a better, more efficient constructor to use with New-Object.

In the real world, you can’t script for very long without needing to use some .Net in your scripts. Most intermediate users, upon finally learning .Net, are surprised to find that they have already been using it for years and didn’t even know it.

If you really want to study .NET functionality, you probably have to sit down with a C# reference book. C# 5.0 in a Nutshell is one such book.

Print ISBN:978-1-4493-2010-2 | ISBN 10:1-4493-2010-4
Ebook ISBN:978-1-4493-2009-6 | ISBN 10:1-4493-2009-0

A lot of the concepts may be way over your head, especially if you have no prior programming experience, but there’s no other book I know of that covers as many aspects as this one.