Previously I blogged about an MSBuild Presentation that I was going to conduct at the JaxDug. I'm pleased to say that the presentation went well. I prepared a Powerpoint, but I decided to not use that and to discuss the various elements by example. I think that ended up being a lot more effective, and interesting than the Powerpoint would have been. You can find all the files for download below. The zip file contains all the files. The ppt is the Office 2003 version.

MSBuild_Sayed_I_Hashimi_012008.zip

MSBuild_Sayed_I_Hashimi_01-2008.pdf
MSBuild_Sayed_I_Hashimi_01-2008.ppt.zip
MSBuild_Sayed_I_Hashimi_01-2008.pptx.zip

Sayed Ibrahim Hashimi

On Wednesday January 9 I will be giving a presentation on MSBuild at the Jacksonville Developers User Group. You can read about the presentation at http://cs.jaxdug.com/blogs/events/archive/2007/11/20/1964.aspx. If you are in the Jacksonville Florida region and are interested in this presentation please drop by. MSBuild is a tough topic to present on because it is not well known and a little confusing. My goal is to create a presentation that is interesting enough to keep people awake yet give people some knowledge that they can use. Also I aim to create some samples that can be useful for demonstration to go with it. If you have suggestions please drop me a note.

Sayed Ibrahim Hashimi

MSBuild: How to get all generated outputs

Earlier today a reader of my book emailed me the following question

I am trying to get a list of all the files being generated when MSBuild build a  certain project (they should be all the files in .bin directory).

When I used the TargetOutputs in MSBuild task it gives me the main output only, which is the .exe or .dll. But any other files like dependency assemblies will not be listed in the TargetOutputs collection.

Any advice??

So it sounds like he is looking for a generic way of determining all the files that have been created (moved) during the build process. I’m assuming that he has a few projects and is using a build script to run the process, and then he wants to move the files to another location. If you have a few projects, then obviously the easiest way is to manually examine the output paths of each project and copy the file as necessary. This is not an ideal scenario, because if you add a project to your process you have to make sure to remember to perform the copy manually. Anywayz, this type of behavior would be useful in many different scenarios. Now let’s talk about how to achieve this.

I took another look at the Microsoft.Common.targets file and determined that there is not a straight forward method of performing this action. So, after thinking about this for a little while I think I have come up with a solution. It’s a little confusing, but actually quite simple.

The solution lies in what I’m calling “MSBuild Inheritance”, which I’ve blogged about previously in the entries at:

·        MSBuild Property & Item Overide Problems

·        MSBuild: Find Many Project References

This is where you take an existing MSBuild file and without modifying it you add behavior and or data to it. Now let’s see how this idea can be used to add the desired behavior described above. For this sample I have created a sample Windows Forms app, as well as an external build script, buildWrapper.proj. This build file is shown below.

    $(MSBuildProjectDirectory)\WindowsApplication1.csproj

             Properties="ImportProjectFile=true" Targets="Build">

        @(ProjectOutputs,'%0a%0d    ')" />

        Condition="'$(ImportProjectFile)'=='true'"

        DependsOnTargets="$(BuildDependsOn)"

        Outputs="@(AllOutputs->'%(FullPath)')">

What this does is twofold:

1.      Defines the GetOutputs target which will drive the process

2.      Extends the behavior of the normal build to create the proper outputs

If you take a look at the Microsoft.Common.targets you will see that the default definition of the Build target is defined as follows:

        Name="Build"

        Condition=" '$(_InvalidConfigurationWarning)' != 'true' "

        DependsOnTargets="$(BuildDependsOn)"

        Outputs="$(TargetPath)"/>

The purpose of this target is to define what targets it depends on and to create the outputs, by itself it doesn’t actually perform any action. Because of this we can override it in our buildWrapper.proj file. So the bottom half of the buildWrapper.proj file will conditionally import the project file and then conditionally re-define the Build target. Inside the new Build target we simply examine the output directory and create an item that contains all files that lie underneath it. In the image below you will see the result of this, specifically take a look at the region highlighted in red.

Now we can see that we have successfully achieved our goals.

Every time I describe this process I feel like it is still un-clear. If you have questions please let me know.

Sayed Ibrahim Hashimi

You can download all the files at http://www.sedodream.com/content/binary/OutExample.zip

(Edit: Updated MSBuild task usage to include Targets="Build")

The MSBuild team is trying to prioritize their duties for the next release of MSBuild. Because of this they have asked for feedback on how their customers (us) would enhance MSBuild. They are doing this by distributing a virtual $100 across a possible 11 items. Their list actually ends in an item numbered 12, but there is no number 10. Here is a brief overview of their list of options.

1. Higher Preformance
2. VC Support
3. Support for other project types
4. Convert VS solution file to MSBuild format
5. Better dependency tracking
6. Distributed Build
7. Inline Tasks – ie you write a script right in your MSBuild file instead of a compilied .NET task
8. Scoping for items/properties – ie items/properties can exist in a defined scope
9. Extensible functions – ie being able to add items like the Exists function
11. MSBuild debugger
12. MSBuild visualization 

Here is how I chose to distribute my $100. 

4   - $40
6   - $10
7   - $10
11 - $30
12 - $10

About #4: In my experience, you have 2 scenarios that are the correct way to create build scripts for products. Those are

1.      Create a custom MSBuild file that acts like a solution file

2.      Use a solution file to drive the build process

The only reason to go with 1 is because the solution file is not an actual MSBuild file, otherwise that wouldn’t even be an option. As for option 2, this is not ideal either because it is difficult to inject steps into how the solution build process works. All you can do is really extend what happens before/after the process.

As for the debugger, this is a tool that I have actually wanted to write myself for a long time, but never had the time. If there was a debugger for MSBuild, I think that more people would begin to adopt MSBuild as well as get a much better understanding of how it works.

It’s not often that teams from Microsoft ask for straight customer feature feedback, if you’re interested in future versions of MSBuild then you should definetly participate in this at: http://blogs.msdn.com/msbuild/archive/2007/11/17/how-would-you-spend-100-on-msbuild.aspx. 

Sayed Ibrahim Hashimi

I’ve created a new release of MSBuild tasks, at www.codeplex.com/sedodream. This release includes 4 .NET 3.5 tasks built on Visual Studio B2. Those are all Linq MSBuild tasks. They are:

The first three tasks simply wrap the SqlMetal command line utility. The last, CreateDatabse, will create a database from a Linq DataContext that is contained in an assembly. Right now there is little validation of the parameters passed, but I plan on adding additional validation. Also I will add more meaningful error messages, when invalid parameters are passed through.

Below you’ll find an example of the CreateLinqCode task.

xml version="1.0" encoding="utf-8"?>

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

  <Import Project="$(MSBuildExtensionsPath)\Sedodream\Sedodream35.tasks"/>

  <Target Name="Create">

    <CreateLinqCode

      CodeFileName="ibrahimTest.cs"

      ConnectionString="data source=(local);initial catalog=ibrtest;integrated security=SSPI;packet size=4096"

      Timeout="15"

      Language="C#"

      ContextClassName="IbrTestDataContext"

      IncludeViews="true"

      IncludeSprocs="true"

      IncludeFunctions="true"

      TargetNamespace="Sedodream.Linq.Test"

      >

    CreateLinqCode>

Target>

Project>

Here is the CreateLinqDbml task usage.

xml version="1.0" encoding="utf-8"?>

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

  <Import Project="$(MSBuildExtensionsPath)\Sedodream\Sedodream35.tasks"/>

  <Target Name="Create">

    <CreateLinqDbml

      DbmlFileName="ibrahimTest.dbml"

      OutDir="."

      ConnectionString="data source=(local);initial catalog=ibrtest;integrated security=SSPI;packet size=4096"

      Timeout="15"

      Language="C#"

      ContextClassName="IbrTestDataContext"

      IncludeViews="true"

      IncludeSprocs="true"

      IncludeFunctions="true"

      TargetNamespace="Sedodream.Linq.Test"

      >

    CreateLinqDbml>

  Target> 

Project>

Please let me know if you have any questions/comments about these items.

Sayed Ibrahim Hashimi