The better way to customize build and create your own steps would be using the MSBuild project file standard directly. Please see:
http://msdn.microsoft.com/en-us/library/wea2sca5%28v=vs.90%29.aspx[
^],
http://msdn.microsoft.com/en-us/library/7z253716.aspx[
^].
You can create your own code for a custom step, which cannot be something better than the application or a batch script to be launched as a separate process. The better approach is to develop the custom Task assembly using MSBuild API. This assembly gets all required information from the build process and the project (options, file names, parameters) and can manipulate them and is expected to produce output integrated into the build process. This is a very well-designed, well-integrated and robust approach, with all elements highly standardized. At the same time, you can easily integrate 3rd-party build code, and even 3rd-party build applications without source code (which I would not prefer). It correctly works with time stamps, incremental build and rebuild, cleaning, all that. Please start here:
http://msdn.microsoft.com/en-us/library/ms171466%28v=vs.90%29.aspx[
^],
http://msdn.microsoft.com/en-us/library/7z253716.aspx[
^].
Note that you can easily organize the build to have your custom Task assemblies compiled before other steps and then used in the build, so you don't need to have any executable, only pure source code. This is much better for good maintenance.
In a pinch, for solving simpler problems you can use the approach explained in Solution 1. But the custom steps based on such approach look and behave like "foreign" elements and are not as good for maintainability.
—SA