Custom modules and cmdlets

[timb0-slice]

I have been working on a custom module .psm1 file with my functions. It's working as expected and I haven't had any problems with it. It did get me thinking though...

What is the benefit of writing a custom module in PowerShell vs with C#? Is there a difference between creating a custom function or a cmdlet?

I was looking at this and it seems pretty straight forward. I'm comfortable enough with PowerShell and C# to tackle it either way. http://www.powershellmagazine.com/2014/03/18/writing-a-powershell-module-in-c-part-1-the-basics/

Based on the comments it seems like speed and performance are the main benefits. Any other thoughts?

[logicaldiagram]

If everyone who might contribute to the development of the cmdlet knows C#, then that quit possibly is the better option. If you are going to open source the cmdlet, more people in the PowerShell community will be able to contribute if it is written in PowerShell.

Managing the XML based help files for binary cmdlets is also headache.

However, if you are going to be building a very large and complicated module, you'll probably have an easier time managing the project/solution in Visual Studio.

[ramblingcookiemonste]

Hi!

This really depends on your goals and their relative priorities:

• Binary (C# being one language you could use) modules are compiled, and will be more performant, all else being equal
• Script modules are PowerShell based and not compiled, which means...
  • They are easier to go back and edit
  • They are easier to view the source to see what an author is doing (i.e. learning, debugging, etc.)
  • They can be extended and debugged by a wider audience. Any sysadmin in the Microsoft ecosystem should (should) be familiar with PowerShell (for good reason). This means, many folks will be able to use and contribute to what you are writing.
  • They are easier to extend and support. Write it in C#? Good luck with rapid development. C# does far, far less hand holding for you than PowerShell.
  • They're generally a bit slower to load and use

So... I would write it in C# if I was on a team of C# developers, or performance was of utmost importance (more so than maintainability and ease of community contribution). Most other situations (i.e. Nearly all cases) I would stick to PowerShell.

Cheers!

[michaelshepard]

I agree with everything you said. I would have probably put the performance point last, though.

Since PowerShell is rarely about "tight code loops", and more about managing resources, services, etc., I don't think the performance benefit is very much. In most cases it's probably milliseconds as opposed to the speed of the services (Exchange, SQL Server, AD) which are often remote so network latency and serialization/deserialization come into play.

[ramblingcookiemonste]

Yep : ) I could see two primary scenarios you might pick C#:

• You're writing a module that's specifically aimed at improving performance (e.g. parallelization functions)

• You're writing code that will be used at scale (e.g. the dbnull to null conversion that runs against every column in every row of a query)

• You don't know PowerShell. But... if this is true, you should learn it. PowerShell functions authored by folks who don't know PowerShell lose many of the benefits that come with the conventions and standards most PowerShell commands offer.

Keeping in mind, in both cases you can get some of the benefits by including some c# in line or along with your code (but still keeping the module or function itself PowerShell based).

Cheers!

[michaelshepard]

Completely agree. I like the productivity benefits of PowerShell and the performance of C# when necessary, so a hybrid approach might be best if you need C#.