One of the cool new features of MSBuild 4.0 is the extensible task factory. Writing your own task factory will allow you to write inline tasks in Perl, Python, or in this case… Windows PowerShell.
Blog post MSBuild Task Factories: guest starring Windows Powershell.
Sample task factory on MSDN Code Gallery MSBuild Windows PowerShell Task Factory.
Deployment is one of the software project taxes that are often neglected or shunted aside to have another team deal with.
There are two big downsides when a team does not directly own it’s deployment. The first is obvious, if the quality of the deployment infrastructure isn’t any good, users perception of your software will suffer. Rightfully so, any you find yourself spending time fixing bugs that are only tangential to your project.
Typically during an overview of some new technology they will say “and it’s totally configurable” at which point my inner sarcastic voice pipes up in response “great, now we have two problems”.
Configuration files are getting bigger and more complex. In some ways this is a good thing as there’s a move towards a declarative approach, but in other ways it’s unneeded as the cost of compilation has gone down. The real problems with the move towards configurable everything is the configuration files often lack designer support, and do not get verified at compile time.
In this post I will only discuss the way to configure SilverLight unit tests to run completely automated from MSBuild, so that it can also be used as part of continuous integration setup.
SilverLight tests must run within an actual SilverLight plugin rather then .NET Framework. Fortunately, Microsoft provided a test framework and source code for the both SilverLight controls and unit tests.
MSBuild is part of our continuous integration process. Syncing to Subversion’s latest changes is done using the SvnCheckout Task (MSBuild Community Tasks Project). The revision number is then captured.
Subsequent tasks create staging/deployment targets, based on the revision – C:\deployment\389. This approach allows us to quickly review a directory tree and locate releases by revision.
MSBuild Item Groups allow wild cards, for example **\*.* tells MSBuild to build a recursive list of all files in all subdirectories. The wrinkle is MSBuild resolves Item Groups when the script is loaded.
