Move definitions of BeforeBuild and AfterBuild targets to .props instead of .targets files

The BeforeBuild and AfterBuild targets are currently defined in Microsoft.Common.CurrentVersion.targets. I presume that the intention was for you to override them in your project files after the .targets import near the bottom of the file.

However, if you’re using the new Sdk attribute on the Project element, it’s not possible to put a target definition after the default .targets import. This can lead to targets that people put in their project files unexpectedly not running, with no indication why unless you examine the log file and see the message that the target has been overridden (for example, https://github.com/dotnet/sdk/issues/841).

It would be better to define the empty BeforeBuild and AfterBuild targets in a .props file so that if they occur in the body of a project the ones from the project take precedence.

@AndyGerlicher @rainersigwald @cdmihai What do you think about the compat implications of this and when we could make such a change? If we changed it for all situations, then targets defined in the “wrong” place in project files would start running where they hadn’t previously. If we are not OK with that, we could change to conditionally defining these targets where they currently are, and then define them in a .props file of the .NET SDK along with a property telling the default MSBuild targets not to define them.

[cdmihai]

A workaround is to use SDK imports:

<Project>
  <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" />
...
  <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" />

  <Target Name="BeforeBuild">
...
  </Target>
</Project>

[terrajobst]

What is the recommended replacement?

<Target Name="MyCode" AfterTargets="AfterBuild" />

– or –

<Target Name="MyCode" AfterTargets="Build" />

– or –

<PropertyGroup>
  <BuildDependsOn>$(BuildDependsOn);MyCode</BuildDependsOn>
</PropertGroup>

<Target Name="MyCode" />

They aren’t equivalent as they have different behavior (and there are probably more ways to do that). We should agree what the right replacement is and recommend it in our docs.