Currently, a package can have logic that runs after common props or after common targets, but we also need to hook in after the users settings but before common targets.
For now, I'm setting CustomBeforeMicrosoftCommonTargets, but that's a hack that hijacks something that should belong to the user. We need to design a way for nuget packages to do this without stepping on anyone else.
cc @jeffkl
The SDK no longer uses a hack because it is no longer imported as a nuget package and can control when common targets are imported as it wishes. But the issue still exists for any other package extending the build via nuget and needing to run before common targets.
This is still not early enough for some things like https://github.com/onovotny/MSBuildSdkExtras. I tried using CustomBeforeMicrosoftCommonTargets, but it was still too late as some of the SDK's targets already calculate things like the define's and AssemblyInfo data by the time it hits CustomBeforeMicrosoftCommonTargets.
We need an extensibility point that gets called before any SDK targets.
The features of https://github.com/Microsoft/msbuild/pull/2014 now enable implementing a new property that holds a list of targets to import.
=> AdditionalProjectsBeforeMicrosoftCommonTargets?
@nguerrera is @dasMulli's suggestion enough for you?
Yes, that's great. TIL.
This would still track adding the property and importing it, so I think we should triage out of discussion.
Most helpful comment
This is still not early enough for some things like https://github.com/onovotny/MSBuildSdkExtras. I tried using
CustomBeforeMicrosoftCommonTargets, but it was still too late as some of the SDK's targets already calculate things like the define's and AssemblyInfo data by the time it hitsCustomBeforeMicrosoftCommonTargets.We need an extensibility point that gets called before any SDK targets.