Would like to migrate away from Batch files and use...?

We currently use Batch files to load procedures, execute script files and 开发者_JS百科call stored procedures by calling the sql sefver utilities cmdutil, dtexec, and osql.

Based on the value of the returned exit codes, we determine the next step to run.

Batch files seem a little primitive to me and I imagine that I would be happier writing this "job control flow" code in a driver .NET program, but I assume that most developers would choose to use some sort of scripting language to do this.

I am considering using VB WSH Script since it appears to give me better language constructs (eg, if then else) and access to COM objects, but I suppose that even that is a little dated and that I should be looking into Powershell.

My question is this:

What are the advantages/disadvanagtes of using Powershell over compiled .NET code for developing a Workflow control program? I suspect that the development environment and compile time checking using the Visual Studio IDE would make me more productive than using script.

I was doing a hello world app to try and utilize one of my .NET libraries from PS and I got the impression that PS just blows over bad code. Does it have sufficient error handling capabilities compared to compiled .NET code?

Powershell can do anything that you would in a batch file and anything you can using C#.

It is a very good scripting language ( the ease with which you can script in Ruby and Python can be found in Powershell as well ) and there are some nice IDEs for it as well. Given that it is not completely supported in VS, there are some efforts in that area as well like the PowerGUI VS

With Powershell you can do error management using exit codes like you would elsewhere and also try-catch exceptions and other constructs like trap, throw etc. Error management is rich in Powershell. You can also use C# code in Powershell using cmdlets like Add-Type.

Subjective part of the answer:

I suspect that the development environment and compile time checking using the Visual Studio IDE would make me more productive that using script.

What you seem to want to do seems ideal for scripting. And Powershell is the natural choice for scripting on Windows. I don't see how "compile time checking" makes you more productive, I would have thought scripting languages had the advantage of making you productive.

I don't really understand what you mean by PS just blows over bad code - but Powershell is just like any other language and bad code or not depends on how you are writing the code.

There is perhaps also the possibility of using ironpython? That is of course if you much prefer python to powershell and are able to install it on whatever machine running the scripts. You have a nice developing environment for it in visual studio as well.

Powershell / .net dev depends on the type of developers you have. probably not a lot of different performance for the type of task you are looking at. Possible answer would be to code in .net and put it all together using powershell as powershell can integrate with.net and all methods fine. Accessing com object from .net not that much fun, easier in powershell maybe..

I agree with the answers saying you can do anything with PowerShell. You can. And the error handling is more than adequate for typical flow control. What interests me is your question about scripting versus compiled languages.

There's a fundamental difference between the tools. A compiled language is a black box, while a script is malleable. Both are equally malleable to their respective developers, but once a program is compiled and deployed to 100 servers, the .exe file's immutable and opaque to all but the developer. When you deploy a script to 100 servers, 100 admins can all look at it, borrow from it, utilize it in flexible new ways.

PowerShell allows the 5 admins on my team to nose through my code without having an MSDN license, right on the server where the code is running. They can borrow, tweak, and come to understand what's happening. And admins from other teams can do the same, without figuring out which CVS repository to check out.

I would recommend small scripts, easily piped together, with moderate comments. Someday, they might actually be read by someone. :-)