Don't stomp on *DependsOn properties #2

[JanKrivanek]

Context

There are couple sdk ***DependsOn properties that allow injecting custom target as dependencies of sdk targets. However big portion of those properties are force set within sdk.targets - so users'd need to include sdk.targets explicitly to be able to set them (we even document a need for this workaround in the documentation mentioned below).

#4922 fixed couple, #9703 fixed one, but we have still dozens that we force overwrite.

e.g. the externally documented Commonly overridden DependsOn properties

• BuildDependsOn :

  msbuild/src/Tasks/Microsoft.Common.CurrentVersion.targets

  Lines 891 to 895 in 23f7752

  	<BuildDependsOn>
  	BeforeBuild;
  	CoreBuild;
  	AfterBuild
  	</BuildDependsOn>

• CleanDependsOn:

  msbuild/src/Tasks/Microsoft.Common.CurrentVersion.targets

  Lines 5675 to 5682 in 23f7752

  	<CleanDependsOn>
  	BeforeClean;
  	UnmanagedUnregistration;
  	CoreClean;
  	CleanReferencedProjects;
  	CleanPublishFolder;
  	AfterClean
  	</CleanDependsOn>

• CompileDependsOn:

  msbuild/src/Tasks/Microsoft.Common.CurrentVersion.targets

  Lines 3595 to 3607 in 23f7752

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

But there are others that seem as potentially usefull - CoreBuildDependsOn, RebuildDependsOn, RunDependsOn, PublishDependsOn etc. etc.

Suggestion

Select a usefull subset (or probably all?) of the DependsOn properties in common target files (search) and redefine those with the additive pattern:

<SomeDependsOn>
   value1;
   value2
</SomeDependsOn>

--->

<SomeDependsOn>
   $(SomeDependsOn);
   value1;
   value2
</SomeDependsOn>

[baronfel]

Enforcing this rule could be an interesting BuildCheck

[JanKrivanek]

Enforcing this rule could be an interesting BuildCheck

Would such properties by manualy configured by the author+user, or might there be any 'magic' how to detect properties that should actually behave as items?

[JanKrivanek]

Punting - no strong consensus