What is the difference between a PreBuildEvent, BeforeBuild target and BeforeCompile target in MSBuild?

Solution 1:

The answer to this question can be found in the Microsoft.Common.targets file which can be found (depending on wether you're using the 64-bit or 32-bit framework) at: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.target for 64-bit and C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets for the 32-bit runtime. This file defines all the steps a build of your project undergoes. Quoting the source:

<!--
============================================================
                                    Build

The main build entry point.
============================================================
-->
<PropertyGroup>
    <BuildDependsOn>
        BeforeBuild;
        CoreBuild;
        AfterBuild
    </BuildDependsOn>
</PropertyGroup>

The code is nice enough to explain the use of the BeforeBuild and AfterBuild target in the comments for both targets.

<!--
============================================================
                                    BeforeBuild

Redefine this target in your project in order to run tasks just before Build
============================================================
-->
<Target Name="BeforeBuild"/>

<!--
============================================================
                                    AfterBuild

Redefine this target in your project in order to run tasks just after Build
============================================================
-->
<Target Name="AfterBuild"/>

This is followed by the definition of the CoreBuild target:

<PropertyGroup>
    <CoreBuildDependsOn>
        BuildOnlySettings;
        PrepareForBuild;
        PreBuildEvent;
        ResolveReferences;
        PrepareResources;
        ResolveKeySource;
        Compile;
        UnmanagedUnregistration;
        GenerateSerializationAssemblies;
        CreateSatelliteAssemblies;
        GenerateManifests;
        GetTargetPath;
        PrepareForRun;
        UnmanagedRegistration;
        IncrementalClean;
        PostBuildEvent
    </CoreBuildDependsOn>
</PropertyGroup>

So the Build target is just a wrapper around the CoreBuild target to enable you to perform custom steps just before or after the CoreBuild target. As can be seen above the PreBuildEvent and PostBuildEvent are listed as dependencies of the CoreBuild target. The dependencies of the Compile target are defined as follows:

<PropertyGroup>
    <CompileDependsOn>
        ResolveReferences;
        ResolveKeySource;
        SetWin32ManifestProperties;
        _GenerateCompileInputs;
        BeforeCompile;
        _TimeStampBeforeCompile;
        CoreCompile;
        _TimeStampAfterCompile;
        AfterCompile
    </CompileDependsOn>
</PropertyGroup>

Again BeforeCompile and AfterCompile are commented in the code:

<!--
============================================================
                                    BeforeCompile

Redefine this target in your project in order to run tasks just before Compile.
============================================================
-->
<Target Name="BeforeCompile"/>

<!--
============================================================
                                    AfterCompile

Redefine this target in your project in order to run tasks just after Compile.
============================================================
-->
<Target Name="AfterCompile"/>

Given this information I do not know why AppHarbor does not support Pre-, PostBuildEvent while the Build can be modified using Before-, AfterBuild.

Choosing which Target to override for which scenario depends on the moment during the build at which you wish to perform your given task. The targets do not have specific restrictions and/or benefits as to what they can accomplish. Apart from the fact that they can adapt ItemGroup's or properties that were defined/filled by previous steps.

Using nuget to bring in packages is probably best performed before the build tries to resolve the projects dependencies. So BeforeCompile is not a good candidate for this kind of action.

I hope this sheds some light on the matter. Found another nice explanation on MSDN