One measure of the fact that MSBuild is a new programming technology is that you don't need Visual Studio to use it. It's part of the .NET Framework so it can be downloaded and used free of charge. Since you can create XML in any text editor and you can use MSBuild from the command prompt, this is another sophisticated software system that Microsoft doesn't charge a cent for. (One might ask, "How do they ever make any money?") Microsoft likes to say that XML is eXtensible like XML itself and it's made for "authoring".
The idea behind MSBuild is to describe what you want done in an XML file. The MSBuild program reads the XML file and maps the elements and attributes to managed .NET programs. You can use the programs that Microsoft supplies - the compiler, for example - or you can write your own. This ability to include your own programs written in Visual Basic as part of the MSBuild executed process is where it really gets eXtensibility. Since you can include your own code, there sky's the limit!
Rather than a fixed sequence of actions to build the solution, MSBuild gives you a framework that you can fill out with the actions that you want to use - and Visual Studio comes with the completed MSBuild files to do any standard builds plus a few more tricks.
A .vbproj file for MSBuild may contain these core XML elements:
- Project
- ItemGroup
- PropertyGroup
- Choose
- UsingTask
- PropertyExtensions
- Target
- Import
To give you an idea about how these elements are actually used by MSBuild, here's the traditional "Hello World" program in MSBuild:
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Hello">
<Message Text="Hello MSBuild"/>
</Target>
</Project>
You can run this program from a command prompt. Just copy and save it in Notepad and then run it from the command prompt. (Note that Windows has to be able to find MSBuild. Run the SDKVars.bat file for Framework 2.0 to set your Windows environment correctly.) The illustration below shows the command to run this MSBuild file and the result.
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
The overall form of the the usual MSBuild file will look something like the example below. (The elipses are replaced by the information that is actually needed for the build - libraries, source files, parameters, and so forth.)
<?xml version="1.0" encoding="utf-8"?>
<Project ... >
<PropertyGroup ... >
...
</PropertyGroup>
.
.
.
<ItemGroup>
...
</ItemGroup>
.
.
.
<Import ... >
...
</Import>
<Target ... >
...
</Target>
</Project>
These elements allow actual processing to take place during the build. For example, suppose a PropertyGroup element is coded like this:
<PropertyGroup Condition="'$(AnotherProperty)' == 'value'" >
<Element1>Element1Value</Element1>
</PropertyGroup>
If AnotherProperty is equal to 'value' then Element1 is set to Element1Value. It's non-procedural and it's certainly not Visual Basic, but it's code.
At the very end of a .vbproj file in a standard Visual Studio Windows application, you'll find this statement:
<Import Project="$(MSBuildBinPath)\Microsoft.VisualBasic.targets" />
MSBuildBinPath is a property that tells the system where to find the pre-programmed build targets. If you're interested in knowing what that path is on your system, you can use this statement in the Hello MSBuild program above:
<Message Text="$(MSBuildBinPath)"/>
With what you know so far, you should be able to understand more about the .vbproj files that Visual Studio creates and make simple modifications. But MSBuild is a significant technology that has open-ended possibilities!
