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.