In this walkthrough I’ll take you through the way that I use MSBuild Explorer on a daily basis.

First thing we need to do is start the application. By default it will install a shortcut to your desktop, your start menu and into your startup folder. The shortcut in the startup folder will start the application in a minimised state.

When you first start the application you will see something like this:

Image 1

So there isn’t much to see there. What I would like to do is use the application to automate the building of software within the development team. Currently the dev team has an MSBuild file and lots of batch files which call the MSBuild file with different parameters so that different things are done, e.g. BuildCodeA, BuildCodeB, BuildDatabases, RunStyleCop etc. If a developer wants to do something different, then they need to create a new batch file. That’s a bit cumbersome, especially if you have a fairly complex build process. Plus, if you are in charge of the builds, you don’t want people coming to you to ask for a multitude of tweaks; let’s rather give them the flexibility to manage the builds themselves.

I’ll use a basic build file for this walkthrough:

<Project1>$(DevelopmentRoot)\Project1.csproj</Project1>

<Project2>$(DevelopmentRoot)\Project2.csproj</Project2>

</PropertyGroup>

</ItemGroup>

<Target Name="FullBuild" DependsOnTargets="Getlatest;

CompileCodeA;

CompileCodeB;

CompileDatabases;

RunStyleCop;

StartServices"/>

</Target>

</Target>

</Target>

</Target>

</Target>

</Target>

</Project>

Code Listing 1

As you can see, the Developers can call this file with /t:FullBuild or no target and it will default to performing a full build. How do we know this? Well, the xml tells us what the DefaultTargets are and the Default target has DependsOnTargets and so on... i.e. we need to study the xml. It’s easy in this sample, but in real life your build files are probably thousands of lines of code.

So let’s open this file in MSBuild Explorer and see how it interprets it:

TIP: You can explore a file by dragging it onto the Targets treeview control

Image 2

There are a few things that we can quickly see in this initial screen

1. There are 7 targets available to call.

2. There are 2 Items and 56 Properties available. Remember, environment variables are exposed as properties, so we see a lot more than the three we defined.

3. FullBuild is the default target and its colour coded blue. Note the Key at the bottom of the screen.

4. GetLatest is conditional and the condition is shown in the tooltip.

5. FullBuild depends on several targets, all listed in order as sub-nodes.

Let’s look at what the other tabs show:

Image 3

The Items tab lists the items that have matched on the path we specified. Note that both the Include and Final Include are shown. This helps when you are trying to figure out how your items were constructed.

Image 4

TIP: All columns are sortable.

The Properties tab shows all the properties. Note that here too we see the Initial and Evaluated values so you no longer need to trawl through xml to figure out how a property was constructed.

This project has no imports so we will skip that tab and move to the Source tab which allows you to view the source code in a Text or Browser View

Image 4

TIP: You can edit the text directly in Text view and save it.

That’s a quick walkthrough of what we have got from simply loading the file. Now say your development team is split in two and you have some developers writing CodeA and some writing CodeB. They don’t want to run a full build all the time, so let’s create some favourites.

To create a favourite we first need to configure what we want to run. In the image below, I’ve dragged the Targets that I want for the CodeA developers onto the Targets to Run treeview.

Image 5

I can run these by clicking Run, or save as a Favourite by clicking File – Save.

Image 6

I now have a favourite that I can quickly run:

Image 7

TIP: You can run a favourite by clicking on it and then Run, or by double clicking it.

Because I have added this favourite to my Main 1 tab, the favourite is also available from the System Tray icon for quick and easy access.

Image 8

TIP: You can rename your Favourite tabs in the program options.

If I run the Favourite I get:

Image 9

So BuildCodeA does a GetLatest which means that the developer knows he is running the latest code. But, what if the build file changes! In this case it would be helpful to GetLatest and then kick off another build.

This is where the Pre-Execution tab comes into play. I’ll update it to execute a command before the dev build occurs.

Image 10

So we actually call into the dev build file with /t:GetLatest. Now I know that the developer will have all the latest code they need. Not quite there though. The BuildCodeA favourite and FullBuild etc. run a GetLatest, so now we will be doing it twice and wasting precious seconds.

We need to use the Parameters in this case and make use of the condition we have available:

Image 11

That’s it. Now the developers writing CodeB can add their own favourite and so on.

TIP: Create favourites to automate things you frequently do, e.g. ClearEventLogs, RestartSQL etc.

Another handy feature is Quick Build which allows you to grab snippets of code you may fine online or be debugging and execute.

Image 12

And finally, how many times have you copy / pasted an MSBuild file and then deleted everything except the Projects tag with namespace to start a new file? Now you can create a new file based on the template you have provided from the File menu or system tray icon.

Take a look through the program options to familiarise yourself with what is available.

I hope you find MSBuild Explorer useful…