BeforeBuild should be available in outer builds

[mwpowellhtx]

Steps to reproduce

I have a Bump Assembly Versions project which to this point has worked fine for single target projects. However, in multi-target projects, I am noticing that I may see a +N or sometimes a +N-1 increment, depending on the bump instructions, i.e. like one of the interior platforms unwound its build asynchronously last. This is incorrect, I only want there to be at most a +1 when there is an increment involved. So... Is there a target I can trigger against that represents the overall build and not each target framework?

[mwpowellhtx]

@rainersigwald Any ideas on this one, good sir?

[mwpowellhtx]

Short of having to do more bookkeeping on the version(s) involved, that is. I could open that can of worms in my tool, but I would rather simply trigger on a single build event for the build as a whole instead of for each of the targets involved during the build.

[mwpowellhtx]

That or separate my single multi-targeted project file to several individually targets project files, each of which having its own uniquely tracked version numbers, but this does not seem like an especially great workaround, to me. ... Kind of defeats the purpose of it being multi-targeted in the first place; never mind the packaging headache that would occur.

[jnm2]

Maybe you would find the buildMultiTargeting folder useful? I can't find official documentation at all, but these links might help (Ctrl+F for buildMultiTargeting on each page):

https://natemcmaster.com/blog/2017/07/05/msbuild-task-in-nuget/#step-4---shipping-your-task-in-a-nuget-package
https://oren.codes/2017/01/04/multi-targeting-the-world-a-single-project-to-rule-them-all/#how-it-works

[mwpowellhtx]

@jnm2 Will have to look into that a bit further, thank you for the tidbits.

[rainersigwald]

I'm going to answer the question you're asking, but I'm a bit concerned based on your description of the symptoms that it may not be the root cause of your problem, so we may have to follow up again.

If you're not already delivering this target in a NuGet package, consider making the target conditional.

The condition isn't trivial, because there are a few interesting cases:

1. The project has a single target.
2. The project multitargets, and this instance of the project is the "outer" build that calls the individual ones.
3. The project multitargets and this instance of the project is one of the "inner" builds with a specific TargetFramework.

Common.targets provides $(IsCrossTargetingBuild) for the third case, but we don't have a single propery for "this project multitargets". We generally use:

1. '$(TargetFrameworks)' == ''
2. '$(TargetFrameworks)' != '' and '$(TargetFramework)' == ''
3. '$(TargetFrameworks)' != '' and '$(TargetFramework)' != ''

see the definition of IsCrossTargetingBuild itself:

https://github.com/microsoft/msbuild/blob/07d3c25a1461dfba3fcc1cc9b28cb8accd4e32b9/src/Tasks/Microsoft.Managed.targets#L19-L21

If you know the project multitargets and want the smallest possible thing, you can use Condition=" '$(TargetFramework)' == '' ".

[mwpowellhtx]

@rainersigwald I'm not sure I understand, so this will yield a single overall build, that in turn would trigger my version bump once and only once? If I understand correctly, would yield multiple subordinate packages organized by the parent package?

For reference, currently the bump tasking is invoked BeforeTargets="BeforeBuild".

[rainersigwald]

Thanks for linking to your code. I see now that you're providing a NuGet package, so the right thing to do is to use the buildCrossTargeting folder, which handles the conditionality for you (NuGet imports it only for the "outer" build). @jnm2 was right on target.

so this will yield a single overall build

I don't think I understand this. "Build" is used for a lot of things (formally and informally) in MSBuild-land; can you ask this question without using that word, please?

If I understand correctly, would yield multiple subordinate packages organized by the parent package?

I don't understand this question, can you rephrase?

[mwpowellhtx]

@rainersigwald Sounds like buildCrossTargeting is the right path for me to investigate. Basically, I want to bump once and only once; that is, once regardless whether the subscribing project is single- or multi-targeting.

[mwpowellhtx]

@rainersigwald So the current target would work in the single-targeting use case under the, Condition="'$(IsCrossTargetingBuild)' != 'true'". However, what would the analog outer loop target be when Condition="'$(IsCrossTargetingBuild)' == 'true'"?

[mwpowellhtx]

@rainersigwald I've dug into these a bit and I still do not see anything that jumps out at me as being a once and only once cross targets analog to the BeforeBuild target. Can you confirm? Better yet, inform me as to what those target(s) might be? With the goal being a resilient version bumping strategy that bumps once and only once, regardless of whether single- or multi-targeting.

[mwpowellhtx]

@rainersigwald Perhaps we could trigger on GetAllRuntimeIdentifiers at a level or two prior to even the Build targets?

[rainersigwald]

You could use BeforeTargets="DispatchToInnerBuilds" but we should expose BeforeBuild in that case too. Updating the bug title.