Generalize how targets can be provided to cross-targeting build

[nguerrera]

To get things off the ground, I'm having to put an Import of Common\ImportAfter*.NuGet.targets in CrossTargeting.targets. This is undue coupling to NuGet. We need to generalize, but can't import everything in that folder as the rest is not cross-targeting aware.

[rainersigwald]

So the core problem is:

• Build logic that is needed in both inner and outer builds.
• That isn’t nuget-based
• That can’t come in from an import in common.props/targets, because those are too specific for the outer build.

Right?

Should we promote the concept of being a cross-targeting capable target? That is, import $(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.CrossTargeting.targets\ImportAfter\*.targets from Microsoft.Common.CrossTargeting.targets?

Is it enough to have a generalized mechanism for the outer build only, or should these targets always also be included in the inner build? I know the NuGet targets are currently in both.

[nguerrera]

Should we promote the concept of being a cross-targeting capable target? That is, import $(MSBuildExtensionsPath)$(MSBuildToolsVersion)\Microsoft.Common.CrossTargeting.targets\ImportAfter*.targets from Microsoft.Common.CrossTargeting.targets?

Yes. I think this is the simplest solution that removes all coupling and it's perfectly consistent with the inner-build case.

Is it enough to have a generalized mechanism for the outer build only, or should these targets always also be included in the inner build? I know the NuGet targets are currently in both.

I think we should keep the CrossTargeting and Common (inner) ImportAfter separate. Often the outer target will just batch over the TargetFrameworks and dispatch to the inner builds, which is not something to repeat in the inner build. If something is written to handle both cases in the same file (as nuget is today) then they can go ahead an import the same file from both locations, but if we go the other way and do this on everyone's behalf, then we will force some to author tricky conditions to only run in the right cases.

[nguerrera]

@emgarten is also asking for a way to provide targets via CustomAfterMicrosoftCommonTargets or similar to outer build.

[emgarten]

As @nguerrera mentioned, NuGet uses CustomAfterMicrosoftCommonTargets to recursively walk through project to project references. Each project is loaded and a set of targets are added in and executed using CustomAfterMicrosoftCommonTargets. This is done as part of the outer loop, NuGet handles evaluating the inner loop itself.

[nguerrera]

For @emgarten's scenario, I think a feature separate from actual common targets where you can provide a targets file to msbuild.exe invocation and it will import that at the very end would be better. Using CustomAfterMicrosoftCommonTargets has the potential to conflict with somebody else in the spaghetti of targets hijacking it from you. (EDIT: or you hijacking it from them.)

[nguerrera]

@emgarten what if nuget.exe carried a tiny project file that just 1) imported some project by a variable passed in 2) imported your targets, then you build that and pass the user project to it.

[emgarten]

That seems like it would give the same result, I'll try it out.

[emgarten]

@nguerrera projects seem to be evaluated differently when using an import vs pass the project under the project attribute of an MSBuild element. I think the outer build will need to support CustomAfterMicrosoftCommonTargets or a new property to handle this, but inorder to work download level it would be nice to keep this as CustomAfterMicrosoftCommonTargets unless it causes other issues.

[emgarten]

This is blocking NuGet in two ways currently

1. NuGet.exe isn't able to bring its own targets along and use them to recursively walk the p2p graph
2. Pack is unable to run in the outer build (buildCrossTargeting folder is unusable so far)

[rainersigwald]

@emgarten Why does the p2p traversal need to have targets injected? Shouldn't they be installed in the global location (and thus provided to every project)?

[emgarten]

Shouldn't they be installed in the global location (and thus provided to every project)?

That could work, but today NuGet.exe brings its own copy and runs standalone. For scenarios where NuGet.exe is newer or has bug fixes it would be nice to keep the option of using any targets instead of just what MSBuild has.

[rainersigwald]

Ok, so the problem is that the outer build doesn't import $(CustomAfterMicrosoftCommonTargets) (because it doesn't import Microsoft.Common.CurrentVersion.targets), so you can't inject logic into the build.

Sounds like the easiest thing would be to provide a similar hook in Common.CrossTargeting.targets: a final import of $(CustomAfterCrossTargetingTargets). Then NuGet can set both properties and satisfy both the inner and outer builds. Right?

Tangentially: I'm confused by the mention of nuget.exe here. I thought we were going to great lengths to make NuGet restore be driven by MSBuild.