After all, can't I just use notepad and csc.exe as long as I can remember "public static void main"...
First of all, why was it written as a script in the first place? What were the perceived advantages? After all, just because you can doesn't mean you should!
- Transparency: scripts can be opened in a text editor even in the production environment. Systems administrators can see what it is doing. They aren't the sort of people familiar with Reflector, and they probably use PowerShell for many of their tasks anyway.
- Debug: a corollary of transparency. If a script starts to fail in production it can be easy to debug and modify a copy of that script right there in the production environment, and not necessarily by the original developer. I don't just mean by printing the output to screen - stepping through style debugging.
- Modifiable: contentious this one. A system administrator can modify the script as environments change. This is very quick and easy to do without a full-bore compile/deploy cycle from a development team. Agreed, many of the things likely to change will be in a configuration file (you could argue that is all a script is, so why have yet another text file unless it is shared). However, if the script is being modified in the deployed environment then it is not part of the solution it was originally deployed with anymore - this could be remedied with a sleight of configuration management though.
- Purpose: with all the CmdLets available in the base deployment or the Community Extensions or PowerPacks etc. you get some enormous re-use to do the sorts of tasks that it was intended for: managing files, working with the contents of files and objects flowing down a pipeline.
Scripts can be well written feats of engineering: aesthetic, efficient, well factored, readable, maintainable, instrumented, documented, following a common convention/style, deployable etc. I think the issue gets tough when the coding gets complex and starts using a great deal of .Net BCL to get the job done. Sometimes it makes sense to move this code into CmdLets or Plain Old C# Objects (POCO) which you can manage in a more rigorous development practice - critically: unit tested and strongly typed where it helps. These functions we have to feel more comfortable wrapping up (inside Unit Tests, Code Coverage, Static Analysis, FxCop, StyleCop, NDepends etc.) and gaining the purpose that is clearly better expressed within an object oriented .Net project at the expense of the transparency, modifiability and general "Operations" friendliness. I would definitely feel better with a 1000 lines of unit tested C# expressed as objects, interfaces and so forth. It's why the PowerShell folk gave us the continuum from the one-liner, through scripts to CmdLets and even custom hosts etc. The trick is to spot where you are on that continuum and refactor as you move along it; recognising the trade offs and benefits.
When I see a PowerShell script that is managing variables and composed of simple routines and CmdLets fulfilling a simple role I feel comfortable; but when I see hundreds of lines of PowerShell mostly made up of calls into the BCL it makes me feel as if it has lost its way and is perhaps better served being moved into CmdLets or Plain Old C# Objects developed in a traditional C#/Visual Studio environment. I don't want to see PowerShell used as an excuse to slap some script together, and move away from the rigour of our engineering practices.
What do you think defines a script and what defines a C# Command Line EXE / DLL / CmdLet? Is it complexity? Who will be maintaining it? The programming style? Simplicity vs Complexity? Is it the reuse of blending the CmdLets that brings speed and efficiency to a certain set of tasks?