Omar Al Zabir wrote a Code Project article entitled Deployment made simple using Powershell where I added the following comment.
I've been using and extending NAnt for 4 years. It has some really nice things and I've done some amazing things with it. However, my current strategy is to leave it. - It's just converting all my existing stuff that will make it painful and slow.
We plan to use MSBuild for Build Control and PowerShell for Deployment. Currently we use NAnt for both of these things.
The worst thing about NAnt and MSBuild is it's XML. The semantics of the language are limited by XML. XSLT is powerful but painful for the same reason. Neither language supports IF, THEN, ELSE because of the constraints of XML. The most glaring problem with these languages is the lack of Parametrized control. A "Target" has expected input that must be passed by convention, no declaration control, and properties are all "Global". Even parameters used in a small snippet are Global. Hopefully you can see the ramifications of this without me spelling it out.
While NAnt and MSBuild are both extensible, it can be awkward to Extend in a way providing backwards compatibility (see comments on parameters) if you are trying to build a library of scripts. It's VERY easy to break dependent scripts.
With this said, MSBuild still has a future with us. If you want to make build processes that execute with Team Build AND when a developer presses F5, MSBuild is what will facilitate it. In short, it the best way to extend Visual Studio for the foreseeable future.
I still have a temptation to use MSBuild for deployments for this simple advantage - it's part of the Framework starting in 2.0. If a machine has 2.0+ installed, it has the core MSBuild language. This gives you flexibility of pushing scripts to a target server and executing them remotely. Nonetheless, PS is so much more powerful when it comes to working with OS components and it will become standard on the OS, it's just a matter of time before you'll be able to count on availability.
Powershell not only provides Parametrized Procedures but is embraces OO with a vengeance. It naively can work will all .Net Classes, but also ADO, WMI, and COM! You don't have to dance through hoops to get full access to these. If you need to utilize .NET objects, you don't have to write rapper Tasks like you would in NAnt and MSBuild. You may want isolate the access in scripts and Cmdlets, but it's not required.
With all that said, Powershell is "scripting". You don't get strong typing that comes from a compiled language because these things are resolved at run time. It works really hard to make sense of Types but that leaves it resolution at Run Time. Also, PowerShell has new syntax and parsing rules you'll have to learn. It won't be painless to learn and master but it has so much power it will be worth it.
Since that time, we have moved forward on this plan. Our Deployments are all using PowerShell. Omar's article is nice but it really only scratches the surface of what we are doing. No wonder he can call it "Deployments made simple"!
I'm still enjoying PowerShell and learning more stuff every day. We really have not reached a full version 1.0 of our PowerShell deployments replicating all the features used in our NAnt deployments. But it's real close. The major difference is we don't customize a single PowerShell script for a product Deployment. Everything is contained in an XML Configuration file. With NAnt, I often had a dozen custom Build files for a product.
After Version 1.0, I'll start refactoring some large chunks of code into C# libraries called from PowerShell. Much of the reasons are in my comments above. Application code belongs in C# where I have strong typing and can have Unit Tests with Code Coverage. PowerShell is great at some things - piping, consistent command line interface, and portable. It also provides the ability to hot fix some logic in a pinch.
I'll post more about the capabilities and functionality in future Blog entries. It's really cool!