16. July 2009
A few weeks ago I had the pleasure of speaking at Tech Summit for Avanade. Tech Summit is sort of like an internal Tech Ed for Avanade Employees. My talk, of course, was all about PowerShell V2 and how to leverage the features like Remoting, Modules, and Advanced Functions.
Advanced Functions essentially allows PowerShell users to leverage nearly all the features that are available to a developer writing a Cmdlet in C# in functions written in PowerShell script.
After the talk, one question that was brought up was “If you can leverage all of these features in Advanced Functions, at what point would you convert over to C# (or VB .NET) and write a full blown compiled binary Module.
The first is all about performance. Well written compiled code will almost always out perform well written interpreted code. There are a ton of factors here that can come into play, but as a general rule, binaries will be faster than script.
The second reason you may want to stick with compiled code is if you want to include a provider with your Module. A provider presents any kind of data store to a PowerShell user in the same way they are presented the filesystem. You can do things like set-location, new-item, set-itemproperty, cd, ls, md, etc etc. Just as an example, the PowerShell Community Extensions has a provider for Active Directory.
If you are a sys admin that has never cracked open Visual Studio, you obviously will start off with Advanced Functions. However, I would really like to point out that the glide path to compiled C# from Advanced Functions is not super steep. There is a ton of documentation on Beginner Development and how to write your first Cmdlet. So if you are interested at all in learning, I say go for it and jump in with both feet. Even if you are not looking to be a full time software developer, looking at and understanding how a compiled cmdlet is written will bring a deeper understanding to how you use PowerShell.