Sayed Ibrahim Hashimi covers some tasks in the MSBuild Extension Pack in this dnrTV show.

Watch now

I work a lot with MSBuild files, mostly to automate numerous processes in the development lifecycle. I wrote a tool to help me work with MSBuild and today I’ve uploaded it to the web in the hope that it will make the lives of those who use MSBuild every day a little bit easier.

The tool is called MSBuild Explorer and it provides the following features:

• Explore the makeup of your MSBuild files.
• Save Favourites to quickly execute your pre-configured MSBuild Scripts.
• Quickly run a snippet of MSBuild.
• Quickly create a new MSBuild file.

The quickest way to see what the tool really does is to spend a minute or two reading the Example Usage Walkthrough.

You can download Version 1 of MSBuild Explorer here. You will need .Net 3.5.

Version 2 will Require .Net 4.0 and will be available in H1 2010.

Mike

Guy Smith-Ferrier gave a talk covering testing with Windows Virtual PC at the UK & Ireland MVP Open day yesterday. He’s posted his slides and source code online now. He also highlighted the upcoming support for Windows Virtual PC in the MSBuild Extension Pack

Take a look at his post, it’s straightforward and a worthwhile read.

Twelve months ago today the first release of the MSBuild Extension Pack was released on CodePlex. It’s been an amazing twelve months! A big highlight has been the day to day dealing with contributors from around the globe. Without the feedback and contributions, we wouldn’t be where we are today.

It continues to encourage me when I see the weird and wonderful ways that people adopt both MSBuild as a technology and the building blocks that the Extension Pack provides. Other highlights of the last twelve months have to include the relatively low bug count and the consistent stream of downloads.

Looking at the past year from a statistics point of view we have

The next release on our radar is 3.5.5.0 which should ship in early to mid December 2009. As a product, we haven’t seen any change to MSBuild, however the ‘big’ 4.0 release is on its way and in the Beta 2 timeframe you can expect to see a beta of the 4.0 Extension Pack.

I’d like to thank all those who have made contact over the last year and helped make the product better for all of us. I encourage you to continue with the feedback, be it good or bad.

Thank you!

Mike

We’ve just shipped the latest release of the MSBuild Extension Pack! This release contains numerous bug fixes, enhancements and new tasks. You can view the significant changes here.

Download

Mike

Another update to the draft online help for the MSBuild Extension Pack has been posted. We’re looking good for a release of 3.5.4.0 some time over the weekend.

If you are sitting on any issues, please get them in now!

Thanks

Mike

Stephen Cleary has made various enhancements to this great task which will ship in version 3.5.4.0 of the MSBuild Extension Pack

Documentation for the task has just been refreshed and is temporarily provided here

Download the beta code now…

Visual Studio 2010 Beta 1 gives the wider community their first look at what is on offer in MSBuild 4.0. In this post I’ll briefly cover the new BeforeTargets and AfterTargets features.

These targets sit in the new MSBuild.Construction namespace and on initial inspection, they provide you with the ability to plug in targets to alter the execution path of a MSBuild file.

Lets cover this with a basic example. Running the following sample,

we get the expected:

Project "C:\Users\administrator.DEV\Desktop\MSBuild Samples\BeforeAfter.proj" on node 1 (default targets).
  Hello from Default
Done Building Project "C:\Users\administrator.DEV\Desktop\MSBuild Samples\BeforeAfter.proj" (default targets).

Now suppose you wanted to run a target before the Default target. In .NET 3.5 you would use DependsOnTargets as shown with the following:

which would result in:

Project "C:\Users\administrator.DEV\Desktop\MSBuild Samples\BeforeAfter.proj" on node 1 (default targets).
  Hello from DefaultDependsOn
Default:
  Hello from Default
Done Building Project "C:\Users\administrator.DEV\Desktop\MSBuild Samples\BeforeAfter.proj" (default targets).

So what’s wrong with DependsOnTargets? Well, not a lot, however the above implementation does create an explicit bind between the targets and may reduce your ability to reuse the default target efficiently.

Enter BeforeTargets

In MSBuild 4.0 you can achieve the same result by using the following

which results in:

Project "C:\Users\administrator.DEV\Desktop\MSBuild Samples\BeforeAfter.proj" on node 1 (default targets).
  Hello from DefaultBeforeTarget
Default:
  Hello from Default
Done Building Project "C:\Users\administrator.DEV\Desktop\MSBuild Samples\BeforeAfter.proj" (default targets).

So we get the same functionality, but our targets are arguably more reusable. I don’t think there is a need to go and re-write all your code, but remember that you have this feature in your tool belt in 4.0.

Now it may be that I’ve used it a lot, but DependsOnTargets makes a lot of sense to me. It does ‘as it reads’, i.e. the Default target depends on Targets xyz… A minor concern I have with this new feature is that it doesn’t do ‘as it reads’. The first time i saw a sample with this I expected that all the BeforeTargets would run before the named target. Perhaps a better name would be RunBeforeTargets, which makes it clear that the named target will run before all the targets listed. The same logic could be applied to AfterTargets (or perhaps a better named RunAfterTargets)

Enter AfterTargets

In a very similar light, the new AfterTargets feature allows us to run a target after a given target. Running the following sample:

we get:

Project "C:\Users\administrator.DEV\Desktop\MSBuild Samples\BeforeAfter.proj" on node 1 (default targets).
  Hello from DefaultBeforeTarget
Default:
  Hello from Default
DefaultAfterTarget:
  Hello from DefaultAfterTarget
Done Building Project "C:\Users\administrator.DEV\Desktop\MSBuild Samples\BeforeAfter.proj" (default targets).

But DependsonTargets Rules!

So you can see how these two new features provide the ability to easily tweak execution. You can also plug into existing target frameworks without affecting other users. Now what of the DependsOnTargets in 4.0? It still lives on of course and its important to understand the order of execution.

Take the following example:

Would you expect to see DefaultBeforeTarget or DefaultDependsOn execute first? Below is the result:

Project "C:\Users\administrator.DEV\Desktop\MSBuild Samples\BeforeAfter.proj" on node 1 (default targets).
  Hello from DefaultDependsOn
DefaultBeforeTarget:
  Hello from DefaultBeforeTarget
Default:
  Hello from Default
DefaultAfterTarget:
  Hello from DefaultAfterTarget
Done Building Project "C:\Users\administrator.DEV\Desktop\MSBuild Samples\BeforeAfter.proj" (default targets).

So as you can see, order of execution is DependsOnTargets, BeforeTargets, [NamedTarget], AfterTargets.

What do you think of this new feature? Can you think of better names or do they make sense to you?

--- Mike

Stephen Cleary has just checked in the first version of the DynamicExecute task. This will ship in version 3.5.4.0 of the MSBuild Extension Pack, but if you compile the code yourself, you can start using it now.

We’d appreciate any feedback you have. Download

Documentation for the task is provided here

We’ve just shipped the latest release of the MSBuild Extension Pack! This release slipped in schedule a tiny bit but includes over 40 new tasks and represents a 20% increase in our code base.

Thanks to all those who have contributed to making this significant release. Download here

PS, you can catch the latest updates on Twitter: http://twitter.com/msbep

Mike

I recently did an interview with Derek Hatchard covering the MSBuild Extension Pack. You can hear about how it started, what it is and what we have in store for future releases… listen here.

The 3.5.2.0 release has now been uploaded to CodePlex. Thanks to all those who have contributed to this release over the past few months.

In terms of changes, this release is not as large as the 3.5.1.0 release, however it includes some great new additions, enhancements and fixes. For full details of all changes, please see the Version History in the Help File or online help.

Thanks for all the feedback and keep it coming, we’re now working on the 3.5.3.0 and 4.0.0.0 releases.

Mike

Attrice have shipped version 2.3 of their MSBuild Sidekick which now supports the MSBuild Extension Pack.

Download

Hoping to get this next version shipped within the next 3 weeks, so if you are sitting on any bugs, now would be a great time to submit them to the CodePlex site…

Mike

A little over seven weeks ago we released version 3.5.0.0 of the MSBuild Extension Pack which provided over 170 tasks. The response from the community has been very positive and today we are pleased to announce the availability of version 3.5.1.0 which provides over 230 tasks.

There have been almost one hundred changes overall and as far as we know (hope), we’ve maintained backwards compatibility, so your upgrade should be a painless experience.

Here are some of the highlights of the new release.

1. Visual Studio IntelliSense for all tasks

2. Online Help

3. Support for Attrice MSBuild Sidekick v2

4. 70 new tasks / features

For full details of all changes, please see the Version History in the Help File.

Thanks for all the feedback and keep it coming, we’re already hard at work on the next release...

A new homepage for www.msbuildextensionpack.com just went live. It’s fairly basic at the moment but we have some great things to come. The first new feature is online help. The help that is currently hosted is for version 3.5.1.0 which is in beta and due to ship on 1 Dec 2008.

If you haven’t tried the beta yet, please give it a go and let us know how you get on. Please also feel free to comment on our online help. We will continue to ship a standalone chm file with each release.

We expect to be in beta for 1 week (pending feedback) and to ship the 'stable' 3.5.1.0 release on 1 Dec 2008.

What's New: Please consult the Version History page in the Help File for full details

Download

Although most MSBuild applications will happily run with no user interaction, sometimes it may be useful to prompt a user with a confirmation or request a value for use in further, possibly conditional, processing.

In the following simple examples I’ll use a few tasks from the MSBuild Extension Pack to illustrate various options for interacting with the user.

Note that many of the tasks used here provide additional properties for customising their usage. Please consult the latest help file for full details.

Alert and Delay

Although it requires no physical interaction from the user, a simple combination of playing a sound, displaying a message and then giving the user a chance to read the message can provide a simple but valuable user experience.

Sample:

<!-- Play an audible alert -->

<MSBuild.ExtensionPack.UI.Console TaskAction="Beep" Repeat="10" Duration="5000" Frequency="1000"/>

<!-- or play a custom sound -->

<!-- <MSBuild.ExtensionPack.Multimedia.Sound TaskAction="Play" SoundFile="C:\Windows\Media\notify.wav" Repeat="10"/>-->

<!-- Display a message -->

<Message Text="Please take note of this important announcement" Importance="High"/>

<!-- Give the user time to read the message -->

<MSBuild.ExtensionPack.Framework.Thread TaskAction="Sleep" Timeout="5000"/>

Console Interaction

The Console class provides the ability to read a line of input from the user. This can also be used to pause the processing of the file until the user presses an [Enter] key.

Sample:

<!-- Play an audible alert -->

<MSBuild.ExtensionPack.UI.Console TaskAction="Beep"/>

<!-- Ask the user to press enter when ready to continue -->

<MSBuild.ExtensionPack.UI.Console TaskAction="ReadLine" UserPrompt="Press [Enter] to continue..."/>

<!-- Read input from the user -->

<MSBuild.ExtensionPack.UI.Console TaskAction="ReadLine" UserPrompt="Please enter your Name and press [Enter]" ToUpper="true">

<Output TaskParameter="UserResponse" PropertyName="Line"/>

</MSBuild.ExtensionPack.UI.Console>

<Message Text="The user name is: $(Line)"/>

Output:

WinForm Interaction

With so much console use in MSBuild, it can be a welcome break to switch to a Windows Form to interact with the user. The Dialog task provides a way for displaying prompts and gathering normal and sensitive input.

Sample:

<!-- A simple message -->

<MSBuild.ExtensionPack.UI.Dialog TaskAction="Show" Text="Hello. Press OK to continue..."/>

<!-- Give the user the option to cancel processing-->

<MSBuild.ExtensionPack.UI.Dialog TaskAction="Show" Text="Click cancel if you've had enough..." Button1Text="Continue" Button2Text="Cancel" Title="You Decide!">

<Output TaskParameter="ButtonClickedText" PropertyName="Clicked"/>

</MSBuild.ExtensionPack.UI.Dialog>

<Error Condition="$(Clicked) == 'Cancel'"/>

<Message Text="User Clicked: $(Clicked)"/>

<!-- A simple prompt for input -->

<MSBuild.ExtensionPack.UI.Dialog TaskAction="Prompt" Title="Information Required" Button2Text="Cancel" Text="Please enter your Name below">

<Output TaskParameter="ButtonClickedText" PropertyName="Clicked"/>

<Output TaskParameter="UserText" PropertyName="Typed"/>

</MSBuild.ExtensionPack.UI.Dialog>

<Message Text="User Clicked: $(Clicked)"/>

<Message Text="User Typed: $(Typed)"/>

<!-- A prompt for password input -->

<MSBuild.ExtensionPack.UI.Dialog TaskAction="Prompt" Title="Sensitive Information Required" Button2Text="Cancel" Text="Please enter your Password below" MessageColour="Red" MaskText="true">

<Output TaskParameter="ButtonClickedText" PropertyName="Clicked"/>

<Output TaskParameter="UserText" PropertyName="Typed"/>

</MSBuild.ExtensionPack.UI.Dialog>

<Message Text="User Clicked: $(Clicked)"/>

<Message Text="User Typed: $(Typed)"/>

<OnError ExecuteTargets="ErrorTarget"/>

Output:

Assuming I click Cancel, then all processing would stop:

If I clicked continue, we would see

Full Sample

<Project ToolsVersion="3.5" DefaultTargets="Default" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<PropertyGroup>

<TPath>$(MSBuildProjectDirectory)\..\MSBuild.ExtensionPack.tasks</TPath>

<TPath Condition="Exists('$(MSBuildProjectDirectory)\..\..\Common\MSBuild.ExtensionPack.tasks')">$(MSBuildProjectDirectory)\..\..\Common\MSBuild.ExtensionPack.tasks</TPath>

</PropertyGroup>

<Import Project="$(TPath)"/>

<Target Name="Default">

<!-- Play an audible alert -->

<MSBuild.ExtensionPack.UI.Console TaskAction="Beep" Repeat="10" Duration="5000" Frequency="1000"/>

<!-- or play a custom sound -->

<!-- <MSBuild.ExtensionPack.Multimedia.Sound TaskAction="Play" SoundFile="C:\Windows\Media\notify.wav" Repeat="10"/>-->

<!-- Display a message -->

<Message Text="Please take note of this important announcement" Importance="High"/>

<!-- Give the user time to read the message -->

<MSBuild.ExtensionPack.Framework.Thread TaskAction="Sleep" Timeout="5000"/>

<!-- Play an audible alert -->

<MSBuild.ExtensionPack.UI.Console TaskAction="Beep"/>

<!-- Ask the user to press enter when ready to continue -->

<MSBuild.ExtensionPack.UI.Console TaskAction="ReadLine" UserPrompt="Press [Enter] to continue..."/>

<!-- Read input from the user -->

<MSBuild.ExtensionPack.UI.Console TaskAction="ReadLine" UserPrompt="Please enter your Name and press [Enter]" ToUpper="true">

<Output TaskParameter="UserResponse" PropertyName="Line"/>

</MSBuild.ExtensionPack.UI.Console>

<Message Text="The user name is: $(Line)"/>

<!-- A simple message -->

<MSBuild.ExtensionPack.UI.Dialog TaskAction="Show" Text="Hello. Press OK to continue..."/>

<!-- Give the user the option to cancel processing-->

<MSBuild.ExtensionPack.UI.Dialog TaskAction="Show" Text="Click cancel if you've had enough..." Button1Text="Continue" Button2Text="Cancel" Title="You Decide!">

<Output TaskParameter="ButtonClickedText" PropertyName="Clicked"/>

</MSBuild.ExtensionPack.UI.Dialog>

<Error Condition="$(Clicked) == 'Cancel'"/>

<Message Text="User Clicked: $(Clicked)"/>

<!-- A simple prompt for input -->

<MSBuild.ExtensionPack.UI.Dialog TaskAction="Prompt" Title="Information Required" Button2Text="Cancel" Text="Please enter your Name below">

<Output TaskParameter="ButtonClickedText" PropertyName="Clicked"/>

<Output TaskParameter="UserText" PropertyName="Typed"/>

</MSBuild.ExtensionPack.UI.Dialog>

<Message Text="User Clicked: $(Clicked)"/>

<Message Text="User Typed: $(Typed)"/>

<!-- A prompt for password input -->

<MSBuild.ExtensionPack.UI.Dialog TaskAction="Prompt" Title="Sensitive Information Required" Button2Text="Cancel" Text="Please enter your Password below" MessageColour="Red" MaskText="true">

<Output TaskParameter="ButtonClickedText" PropertyName="Clicked"/>

<Output TaskParameter="UserText" PropertyName="Typed"/>

</MSBuild.ExtensionPack.UI.Dialog>

<Message Text="User Clicked: $(Clicked)"/>

<Message Text="User Typed: $(Typed)"/>

<OnError ExecuteTargets="ErrorTarget"/>

</Target>

<Target Name="ErrorTarget">

<Message Text="The user has terminated processing."/>

</Target>

</Project>

Progress on the next release, release 3.5.1.0, of the MSBuild Extension Pack is going well.

Please continue to provide feedback to us via the Discussions and Issue Tracker pages, or email us directly at feedback@msbuildextensionpack.com

We aim to ship 3.5.1.0 in the last week of November / first week of December 2008.

The next release of the MSBuild Extension Pack will offer IntelliSense for all tasks. It’s a small but helpful addition which makes using the tasks that little bit easier.

We will also ship an IntelliSense schema file for the Team Foundation Build Tasks.

In generating this schema file, a few undocumented properties were discovered that you may find useful:

• Get: TeamFoundationServerUrl, Overwrite
• Label: TeamFoundationServerUrl, Scope
• SetBuildProperties: LogLocation, SourceGetVersion

Required parameters have ‘REQUIRED.’ as a prefix in the tooltips shown.

Unfortunately a bug exists in Visual Studio 2008 & SP1 which means that you will partially lose IntelliSense in the IDE if you use schema documented tasks after undocumented tasks. Here is a quick repro:

This repro uses the following simple sample

1. <Project DefaultTargets="IntelliPain" ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
2.          
3.     <Target Name="IntelliPain">
5.         <UnDocumentedTask AProperty="a"/>
7.     </Target>
8. </Project>

Step 1

• Start typing at Line 4.
• IntelliSense on the available tasks is seen.

• Continue typing at Line 4.
• IntelliSense on the available tasks parameters is seen.
• CTRL-SPACE can be used to display the parameter IntelliSense if it is not shown.

Step 2

• Start typing at Line 6 (i.e. BELOW the task which has no associated schema).
• IntelliSense on the available tasks is seen.

• Continue typing at Line 6
• IntelliSense on the available tasks parameters is NOT seen.
• CTRL-SPACE can NOT be used to display the parameter IntelliSense.

This bug has been reported to Microsoft but I don’t know when we can expect a fix. A workaround is to create documentation schema files for all the tasks you write (and use if they don’t already have them). There is some guidance for doing this here, and you will find more guidance in the next version of the MSBuild Extension Pack help file.

If you would like to try out these schema files now, you can download pre-release versions from the CodePlex site.