If Powershell is built on top of .NET, what is the reason for writing scripts instead of C # code?

Question

As a person who is new to Powershell, I am not 100% sure at one point:

If

"In PowerShell, administrative tasks are typically performed by cmdlets (pronounced by commands), specialized .NET classes implementing a specific operation."

What are the reasons for writing scripts instead of writing .Net executables with these classes and compiling them as console applications?

Answer 1

You can just as easily ask the question, what are the reasons for writing applications in .NET, when you can just as easily create full-fledged desktop and server software in PowerShell?

There are reasons to use both in different circumstances. PoSH scripts are just small text files that are very easy to write and maintain. As someone who speaks in both cases, I would say that in many cases system maintenance tasks are much easier to do with a quickly hacked PoSH script than with a .NET application.

This suggests some things that are much easier to do in .NET (I use C # myself), but the process of developing them is much more cumbersome and requires an additional set of skills that is not common among SysAdmins.

Simply put, PoSH targets SysAdmins and .NET targets developers, but that doesn't mean there is no room for crossover.

Answer 2

I totally agree with @Matt G.'s answer.

I just want to add one thing that is an arround culture. The Windows SysAdmin culture is more controlled by "click" (graphical user interface administrator) than program-driven.

I use to work in the Unix world, there, SysAdmins, where the power writers (sh, csh, ksh ...) and when necessary, where they can write a small program "C" in the corner of the table (for playback, or act as complex file filter, etc.).

From the beginning of .NET (2001), Windows SysAdmins can use the C # compiler (accessible from the .NET directories as CSC.EXE), since Linux or Unix could use the cc compiler, but they do not. The best of them used WSH (Window Script Shell), but VBScript was not so easy to use and it needed to detect different COM objects for each case.

Microsoft, multiply the ways Windows SysAdmins are prompted to use command lines and scripts (WSH, netsh, wmic, etc.). For several years (2006), Microsoft decided to take Sysadmins by the hand and provided them with the Power tool, removing power from the user interface (Exchange 2007). So now SysAdmin can do nothing but use PowerShell. But since they are not devotees, the language is interpreted and the "culture of the object" is somehow hidden for beginners.

Now good Windows SysAdmins can develop their own C # class and paste them into their PowerShell scripts, SysAdmins are not developed, they just need to automate their process.