I just got a pretty interesting mail from Dave Hickey at Premera, describing how his team is using MSBuild as a generic scripting language:
We thought you might be interested in how we use MSBuild here. Sure, we use it for compiling our .NET projects, but we’ve adopted it as our new Batch scripting language, replacing a windows-based KSH (korn shell).
We have hundreds of activities that run at scheduled times, fired by Autosys. We’ve created a tool that spawns MSBuild and passes xml project files. We’ve extended the logging so that a state file is also written after each task. When the script is rerun, the state file is checked and the last resumable target is then used. This saves us from having to repeat all steps in a script due to a db deadlock or some other problem.
The main benefits we see using MSBuild for batch are:
· Logging is standardized and built in.
· Projects are resume-able, thanks to a CallTargetResume class we wrote that acts on the statefile.
· Syntax is standardized because its xml. Tools like MSBuild sidekick become available. Very little programming required to maintain, once the toolset is established.
· It leverages all the include, batching and import features you guys wrote.
· Large development community.
· MSDN MSBuild docs for free.
· MS Supported
We considered using Nant, but opted for MSBuild as a standard for the reasons above. Anyway, hope you found this ‘atypical’ use of MSBuild interesting.
Now, MSBuild is intended to be only a language and platform for build processes. Powershell is much more suited to generic scripting, and has some great UI support now too, but to the best of my knowledge it doesn’t have any built-in logging capability yet. That’s one of the things I miss most myself from cmd.exe batch script.