What is PowerShell good for?
When it would be easier to write a script using .NET assemblies than a C# tool?
Ah see, that's just it. PowerShell bridges the divide between batch files and the .NET world. PowerShell answers the question, "What if you were to write a new command interpreter that had all of the power of .NET, was totally dynamic, and had pretty much most of the things that people want in a command shell?"
So when do you use PowerShell over C#? It's a lot more convenient for small apps that integrate or orchestrate other apps -- it's more convenient because you don't have to compile it, AND it already has a standard way of passing data around to other scripts and scriptlets, which is easy for people (who know PowerShell) to understand.
PowerShell is a powerful tool you can use to accomplish several and different tasks which would otherwise require a user using the mouse... (not only).
For example, the latest versions of Microsoft server products like SQL Server, Exchange, SharePoint and so on expose a rich set of APIs that could easily be used with PowerShell, in this light, with PowerShell you can for example:
- attach, detach, backup, restore a database in SQL Server;
- manipulate Exchange mailboxes;
- and much more.
All things which you could not do before simply from a batch file.
For writing a C# tool you typically need to set up a Visual Studio project (or a project in another IDE). If you doing this "manually", you need at least a build script to run the C# compiler. If for a specific task this seems to be too much overhead, and you need just a simple one-file-source-and-program-is-all-in-one solution, a PowerShell script may be the better alternative.
Some possible reasons:
- There is no Visual Studio (or any other C# IDE) installed on your machine, or you are not used to it at all (like a lot of system administrators)
- The program is so small you don't need a debugger. Some simple console outputs will do it.
- You do not want to maintain more than one file.
- You don't want to put configuration parameters for your tool into a separate configuration file.
- When you can define individual tasks, but can't determine an exact workflow, a mixture of script and C# is ideal. Creating cmdlets or providers in C# gives your scripts access to anything in a general way, and PowerShell becomes the glue, making the workflow flexible to new situations.
- You have several competing overarching design ideas and you want to rapidly test the possibilities for feasibility. PowerShell's soft typing and pipeline architecture makes it easy to ignore a lot of the vagaries of control structure and type details and get to the heart of an algorithm.
I'm a C# developer and have been using PowerShell since the beta days when it was still called Monad. I also did a fair amount of development on UNIX including automation/scripting with Korn Shell. For me, PowerShell was a godsend because I was growing tired of Korn Shell's little impedance mismatchs with Windows. For example specifying a network share path was particularly gross "\\\\\\server\\\\share" IIRC. It was a bit of guessing game as to how many times you escaped a backslash depending on how many times the string gets evaluated.
I use PowerShell for a lot of automation tasks such as:
- Grepping through a large source directory where I want to search contents of CSPROJ files.
- I once modified 260+ VCPROJ files with a PowerShell script.
- Another time I had to create a bunch of new C# projects each with a fair number of project properties to be configured including a lot of Code Analysis tweaks. I wrote a script to take a stock C# project file and do all the tweaks for me. Saved me lots of time and more importanty, saved me making a lot of mistakes and/or forgetting to set certain settings
- TFS queries (using the TFPT PowerShell cmdlet) such as search for recent changesets with a certain word in the checkin comment.
- Deleting all temp files (bin/obj dirs, suo files, etc) within a particular folder hierarchy.
To replace custom command line utilities:
You can use PowerShell as a great way to replace all those little command line utilities you used to write. Think about this. PowerShell is a reasonably powerful script language that gives you access to most of the .NET Framework. It particularly excels at parameter parsing i.e. it has a built-in parameter parsing engine that gives you: named parmeters, positional parameters, optional parameters, switch parameters, pipeline bound parameters, parameter validation and more. Now consider how much code in your typical command line utility is dedicated to parameter parsing vs the actual functionality. I've almost stopped writing command line utilties (unless they're particularly complicated - then you can't beat the VS debugger). And I let PowerShell handle all the parameter parsing for me. And with PowerShell 2.0 it is extremely easy to add documentation/usage to your utility by just decorating your script with some appropriately formatted comments.
I also use PowerShell as a .NET REPL:
- Eliminates the need to create ConsoleApplication59 just to see what a formatting string does e.g. I just go to my PowerShell prompt and try something like
"{0,20:F1}" -f 41.22.
You can also take advantage easily host the PowerShell engine within your own C# application. This comes in handy if you provide features to your end users that you would like to make command line scriptable. You can write those features as a PowerShell cmdlet (in C#). Those cmdlets can then be used directly from the command line and if you host PowerShell in your GUI app, you can then access that same set of code from there e.g.:
private bool VerifyPowerShellScriptSignature(string path)
{
using (var runspaceInvoker = new RunspaceInvoke())
{
Collection<PSObject> results =
runspaceInvoker.Invoke("Get-AuthenticodeSignature " + path);
Signature signature = results[0].BaseObject as Signature;
return signature == null ? false :
(signature.Status == SignatureStatus.Valid);
}
}