target-authoring

Append your target to the existing CompileDependsOn property using $(CompileDependsOn);MyTarget rather than redefining it. Overwriting the property silently drops SDK targets like code generation and core compile steps.

Use DependsOnTargets when your target explicitly requires prerequisites you control. Use BeforeTargets or AfterTargets when injecting into a pipeline you do not own, such as hooking CoreCompile from a NuGet package's build folder.

Query targets like GetTargetPath return stale data when they declare Outputs, because MSBuild skips them as up-to-date. Use Returns instead, which specifies what callers receive without triggering timestamp-based skipping.

Directory.Build.targets is imported after SDK targets, so redefining properties like CompileDependsOn there silently replaces the SDK's chain. Always append with $(ExistingProperty) included, and define targets in .targets files rather than .props.

Declare Inputs and Outputs on the core target so MSBuild compares timestamps and skips up-to-date work. Also register generated files in the FileWrites item group so Clean can remove them and incremental builds stay correct.

This guidance covers authoring patterns only, not incremental build tuning, build parallelization, or general MSBuild anti-patterns. It also does not apply to non-MSBuild build systems such as CMake or Bazel.