Why Use .NET Framework Classes from Within PowerShell?

re: Why Use .NET Framework Classes from Within PowerShell?

Brian T. Jackett — Tue, 06 Mar 2012 02:28:34 GMT

To me there is a third option: performance.

When I run both commands with measure-command the static .Net call is 2x-3x faster on my machine. May not seem like much, but to a developer-minded person that could be the tipping of the scales in favor of using .Net vs. native PowerShell commands. Many times when I'm teaching PowerShell workshops I show an example of adding numbers 1 to 10,000 to an array using native PowerShell array vs. .Net generic list. The .Net way is typically 1000% faster than native PowerShell. Raises interesting questions and discussions.

re: Why Use .NET Framework Classes from Within PowerShell?

jrv — Tue, 14 Feb 2012 18:48:02 GMT

@JohnLan –

I was not really considering off-point 'noisy' issues such as job security.

Issues of performance, understandability, portability and conformance to standards, both global and corporate, are what i believe are important areas of discussion. Perhaps there are other areas that should be included as well.

Job security is about an individual employee and has no bearing here.

We can re-interpret 'look cool' to be the readability of a script. To that point I offer the Verb-Noun nature of CmdLets as one good reason to use them over the Net Classes direct method.

In simple everyday scripts I suggest whatever gets the job done without damage to the system s being acceptable. For scripts that are to be shared a nit more discipline may be called for.

I would suggest doing what we have always done in programming when calling a foreign API; encapsulate it.

Example:

function Get-WebFile([string]$fileurl]{

$wc.DownloadFile($fileurl)

}

This can be included in a library module and will allow us to modify its behavior. We can also replace it easily if newer functionality becomes available by just editing one location. The designers of PowerShell have given us the tools to support nearly all standard modes of program design and support. PowerShell is not a second class scripting language. It is a full first class language that supports command line ad-hoc tools and batch scripts along with the ability to be easily extended in almost any direction.

re: Why Use .NET Framework Classes from Within PowerShell?

JohnLan — Tue, 14 Feb 2012 18:04:01 GMT

@jrv: I totally agree there are best practices, I also agree that one way is better, slightly or significantly, than the other from technical perspective; but I just don't see how it would relate to the conclusion that someone tried to make his/her script look cool, or job security discussion etc.

Why not just keep technical discussion to technical?

re: Why Use .NET Framework Classes from Within PowerShell?

jrv — Tue, 14 Feb 2012 17:44:31 GMT

@JohnLan

I will defend the blog. It has begun some good discussion. In programming and in all technical pursuits it is alwasy worthwhile to debate the pros and cons of any widely used methods. I feel we can all learn something from this kind of discussion.

re: Why Use .NET Framework Classes from Within PowerShell?

JohnLan — Tue, 14 Feb 2012 16:23:42 GMT

I see a lot judgemental statements in the posts - I myself really don't see a big difference between using [datetime] static property or get-date cmdlet. It could be just a habit, it could be just whatever came up first in googling when a beginner didn't know how to get current time, then he/she sticks to that method. Either way, big deal.

re: Why Use .NET Framework Classes from Within PowerShell?

Boe Prox — Sun, 12 Feb 2012 03:28:33 GMT

This is a key line in the article: "Keep in mind, that as a best practice, I recommend using a native Windows PowerShell cmdlet when it exists—unless there are compelling reasons for not doing so." In my mind this extends beyond just using static .Net methods but also using .Net classes to build objects that perform the same job as existing PowerShell cmdlets.

Sometimes it is a lack of education when a .Net method is used instead of a cmdlet that can be helped just by advising the individual of the correct PowerShell cmdlet. A number of examples I have seen recently are folks using System.Net.Mail.MailMessage instead of Send-MailMessage and it was just a case of not knowing that this was available. A quick comment on their blog letting them know about this and now they are using the cmdlet in future scripts. Other examples I have seen are using .Net for "pinging" a machine when Test-Connection works.

Other times it might be because of the background of the person writing the script where they have a heavy background as a .Net developer and just simply fall into the habit of what they use the most. It is just like a vbscripter who first steps into PowerShell and wants to continue to write code in a "vbscript way". Sometimes it just takes a little bit of time to adjust to a PowerShell frame of mind when writing the code.

In the case of dates, using a cmdlet is the preferred way to go. But in the case of downloading a webpage, at least in V2, using the .Net method (Net.WebClient) is the obvious best choice to work with until V3 goes RTM and then you can use something like Invoke-WebRequest to accomplish this. When working with Active Directory, it all depends on what you have available in your environment at the time. If you have access to the AD module, then you use that, otherwise you make use of the .Net methods in the way of the type accelerators ([adsi],[adsisearcher]) to accomplish your goal.

Just my 2 cents...

re: Why Use .NET Framework Classes from Within PowerShell?

jrv — Sun, 12 Feb 2012 01:55:06 GMT

#rjcox - sorry I flomoxed that one. Her is the correct version:

PS>(Get-Date).Date

Saturday, February 11, 2012 12:00:00 AM

re: Why Use .NET Framework Classes from Within PowerShell?

K_Schulte — Sat, 11 Feb 2012 22:05:11 GMT

Hi Ed, Hi @all

to cut things short: If you can: make the best out of both worlds!

There are no scary things involved!

PS is based on the Net 2.0 framework, it won't be here, without it!

Use cmdlets if appropriate and well known!

Use .Net 2.0 if you can and if nothing else is knwon to be available the PS way ...

Klaus (Schulte)

re: Why Use .NET Framework Classes from Within PowerShell?

rjcox — Sat, 11 Feb 2012 21:48:35 GMT

@jrv

> Get-date #[DateTime]::Today

These are not the same, [DateTime]::Today includes a zero time (ie. midnight), Get-Date is the current time, so

$someDate -lt [DateTime]::Today

is true if $someDate is yesterday or before.

re: Why Use .NET Framework Classes from Within PowerShell?

JeremyEngelWork — Sat, 11 Feb 2012 17:01:24 GMT

I think there is another aspect we're missing, which is not so negative - Innocence. I for one learned how to code with C++ and then C#, and I might use those without knowing there is a cmdlet equivalent. Of course, when I do discover the "PowerShell Way" I try to convert to using that, but I can't know all things without first learning of it. That's another reason why this site and the articles is so great and important! I learn every day.

And as some of you pointed out .Net is native to PowerShell, so always using the cmdlets over raw .Net classes is nothing more than a subjective value statement. I agree that reading PowerShell cmdlets is easier, but I find instances where using the raw class is better for automation, such as when I build scripts to access AD. The AD cmdlets are great when you have the AD module installed, but most of my computers do not have that. Therefore, I tend not to use it in any of my formal scripts because I value portability across my systems over ease of reading. Conversely, I'll use the AD module cmdlets for one-off queries, or if I know I'll only run a script on computers with the AD module.