MSBuild in Visual Studio Part 11: Other Special Targets

The last two entries walked through how the Compile target is used by the IDE to drive certain features. There are a number of other targets that get called at various times.

Several targets exist to help compute project output groups, which are sets of files related to the project. These are useful when the IDE needs to know the answer to questions like “What are the output files for this build?” or “Where are your source files located?” These targets have pretty obvious names in Microsoft.Common.Targets, such as BuildProjectOutputGroup and SourceFilesProjectOutputGroup.

The easiest way to see one of these targets in action is to add a new Setup project to your solution and then add the “primary output” from your application to the Setup project. When that’s done you can right click on the primary output and select “Outpust”. This will call the appropriate target and display the results in a dialog:

Another group of targets are used to drive reference resolution, which is one of the most complicated parts of a build. Targets such as ResolveAssemblyReferences, ResolveComReferences, and ResolveNativeReferences are used to populate the copy local and path properties for the property grid.

The assembly reference targets are also used by the winforms designers so they can reflect on the correct types at design time.

That’s about all there is to talk about how MSBuild is used at design time by Visual Studio. Next time we’ll talk about how MSBuild is used to, well, build!

[ Author: Neil Enns ]

Comments (2)

  1. Matt says:

    I have a question in relation to resolving references and dependency injection.  If project A depends on project B and project B depends on assembly C, but the dependency between B and C isn’t a compile time dependency, it’s a runtime dependency due to dependency injection, how can I have VS and MSBuild include assembly C whenever project A is built?

    It appears that assembly C is included in the resulting build of project B, but it is not included in the resulting build of project A, probably because the assembly manifest for project B doesn’t list assembly C as a necessary resource.

    Of course, I want to avoid solutions like, including assembly C as a reference in project A and creating an unused declaration in project B to some class in assembly C…


    — Matt