Another session that I attended was presented by a friend of mine, Steve Andrews. Steve is an MVP for the Team System. The goal of this presentation was to inform the audience about the structure of a project and how that integrates with MS Build/Team Build. He started the presentation saying that a .proj file is little more than an XML file that adheres to the ms build schema.
The MS Build schema has 4 main items to understand.
- Properties
- Targets
- Items
- Tasks
An important piece of information is that the .proj files are msbuild files. They identify how to build themselves. Let that sink in for a moment. They create the project associations and dependencies necessary to build themselves. MS Build can natively use these files in its processing.
Some of the Valuable tags in an MS Build file are:
- ItemGroup. It can have a condition attribute 'stringA' != 'stringB' and can conditionally include specific files based on that condition
- Project tag can identify the preTarget or the DefaultTarget to set an order of procedures to complete
- Targets: Identify the way/method to leverage in order to build the solution
- Tasks: identify the individual steps necessary to build the solution. These can be 3rd party tools accessible via command line.
Another note of interest is that TFS and Team Build don't have be used exclusively for .Net projects. If you aren't working with MS products for the back end, there are 3rd party libraries that provide tasks for working with all kinds of functionality (SDC and Tigris). These same libraries offer additional custom tasks to be executed against your built/pre-built solution. Aha, yes! You can build custom tasks that do whatever. Then these tasks can be included in future projects more easily. By extending the Task class, you can create custom tasks with any functionality you need. More about this in a later post maybe.
One great advantage of MSBuild and Team Build is that logging is built into MSBuild. You can leverage the logging mechanism by utilizing the Log property of the Task class. Additionally, instead of extending Task, if you need to custom granularity you can implement ITask instead. This will be substantially more work but at least it offers that ability.
I eluded to TeamBuild and MSBuild separately before. That's because TeamBuild is an extension of MSBuild. It offers the ability to assemble a projects to organize msbuild plus extended properties. It enables the ability to QUEUE builds and trigger builds automatically. Wonderful stuff.
I've been using TFS for years and much of this was new to me. I'll be looking more deeply into this very soon.