MSB4181 vis-a-vis custom MSBuild task targets

[mwpowellhtx]

Borderline to do with MSBuild as much as it is the SDK.

I have a scenario with a netcoreapp3.1 targeted (WinForms, i.e. WinExe) project that is generating an MSB4181 error.

Generally speaking, as tooling, the bumps work, has been proven to do so over a range of scenarios from netstandard to netcoreapp to classical desktop .NET Framework scenarios; but in this scenario we are bumping into the MSB4181.

Literally the project in question is:

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<!-- ... -->
</Project>

I have discovered the SDKs in my syste mare currently:

C:\>dotnet --list-sdks
2.1.518 [C:\Program Files\dotnet\sdk]
3.1.402 [C:\Program Files\dotnet\sdk]

However, I think that probably the build is happening under 3.1.402, which, from at least a couple of other items, is thought to be that the SDK itself broke something along the way, with at least one workaround supposing global.json. Possibly, also, runtimeconfig.json may also be used to workaround the issue.

Assuming either or both of these would successfully workaround the issue, the question for me then is, to which SDK. I don't think my custom MSBuild task assembly necessarily cares what that is, as long as there is support for netstandard2.0. Thinking forward, then there is also the problem of the hole in the middle; what to do with instances of the 3.1.402 SDK, which apparently cause the issue. Maybe this is already supported by global.json and/or runtimeconfig.json, but I am less familiar with those protocols.

Attached is a repro of the issue. Observing the results of the build in a couple of local BAV turns, it seems like the tooling does try to perform what it needs to perform, however, MSBuild is failing to relay the item specs properly via its targets, which tells me that probably something integration-wise broke in terms of MSBuild more than anything else.

bavtest.zip

[marcpopMSFT]

@mwpowellhtx The bavtest project you attached builds for me with SDK 3.1.403 and 5.0.100 and I do not see that MSB error. Can you provide more details on the error you're seeing or provide the binlong

In general, every SDK can target downlevel and we recommend users use the most up to date version of the SDK.

[mwpowellhtx]

Do you see the effect of BAV? Since the most recent VS2019 update, I ran it, and now I do not see that BAV is being invoked whatsoever. In the test case, we expect that an AssemblyVersion should be inserted with default value 1.0.0.0, but this is not happening.

To verify, I edited the installed BAV targets to see if I was getting any invokation whatsoever, and it would seem I am not.

<Target Name="DebuggingBav">
    <Message Text="BAV is attempting to run" Importance="high" />
</Target>

    <!-- This works perfectly in the single-target scenario, but we need to condition our response based on whether TargetFrameworks was there. -->
<Target Name="BumpAssemblyVersionsBeforeBuild" AfterTargets="DebuggingBav" BeforeTargets="BeforeBuild" Condition="'$(TargetFrameworks)' == ''">
    <CallTarget Targets="GeneralBumpAssemblyVersions" />
</Target>

    <!-- BeforeBuild occurs for each of the targets individually in a multi-target scenario, so we must Bump relative to the Outer loop Dispatch. -->
<Target Name="BumpAssemblyVersionsBeforeDispatchToInnerBuilds" AfterTargets="DebuggingBav" BeforeTargets="DispatchToInnerBuilds" Condition="'$(TargetFrameworks)' != ''">
    <CallTarget Targets="GeneralBumpAssemblyVersions" />
</Target>

Which would lead me to believe that, best case, the targets are completely different for WinExe projects. Best case I need to know the targets. Worst case, perhaps, there is a runtime issue that is completely ignoring the build task.

[mwpowellhtx]

@marcpopMSFT For comparison and contrast, I added a class library project, which does at least try to invoke the version bump task. That I can determine in this instance, MSBuild is failing to connect the properties with the task variables properly, specifically the BumpVersionSpec variables. Which leads me to believe there is a possible MSBuild runtime conflict, or that I need to instruct the runtime with a runtimeconfig.json, perhaps, deployed with my BAV.

In any event, I just need some constructive, useful feedback there so I can respond accordingly and make it right.

bavtest-plus-class-library.zip

[mwpowellhtx]

@marcpopMSFT I promise you BAV ran successfully under previous runtimes, MSBuild scenarios. So whatever happened in recent deployments has broken it. Thank you...

[mwpowellhtx]

@marcpopMSFT So in summary, seems to me there are at least two issues piling on there. First, WinForms MSBuild targets are completely different, are not connecting with the BAV targets. Second, a possible MSBuild issue, failing to connect the build task with its BumpVersionSpec variables. Appreciate any feedback you can provide there leading to successful resolution. Thank you.

[marcpopMSFT]

I still have not been able to trigger MSB4181. I can confirm through the binlog that BumpAssemblyVersionsBeforeBuild is being run. You should use DependsOnTargets="DebuggingBav" rather than AfterTargets to ensure it runs. BumpAssemblyVersionsBeforeDispatchToInnerBuilds will only run when multi-targeting.

I'm not familiar with the BumpAssemblyVersion plugin to MSBuild but I have been able to confirm it working in some scenarios and not in others. If I use the 5.0 SDK (that released today) and switch to importing the Microsoft.NET.Sdk, then I see the assembly version being bumped even for a 3.1 targeted application. If I use the 3.1.403 SDK or 5.0 SDK but import Microsoft.NET.Sdk.WindowsDesktop instead, I see that BumpAssemblyVersionsBeforeBuild is run but I neither see the error nor does it appear to succeed.

So my suggestion is upgrade to the 5.0 SDK, switch your first line to be , and see if that works:
BAV is attempting to run
'bavtest.csproj': Bumped 'AssemblyVersion' from '1.0.0.0' to '1.1.20315.1150'
bavtest -> C:\test\bugrepro\bavtest\bin\Debug\netcoreapp3.1\bavtest.dll

[mwpowellhtx]

@marcpopMSFT Version bumps work fine I think as long as the project Sdk is Microsoft.NET.Sdk, that's not the issue at hand. I did a bit of debugging, not officially released through nuget, and was able to determine that for Microsoft.NET.Sdk.WindowsDesktop, that MSBuild does not seem to be relaying the ItemGroup variables to the task.

In terms of inner and outer task loops, yes, I tested in a variety of scenarios, single targeting and multi-targeting, in order to establish which targets would be invoked so that I could bump a single time, depending on the scenario. Mainly, for multi scenarios, I want to prohibit outcomes that would bump multiple times. I think I was successful in that.

BumpAssemblyVersionsBeforeBuild is run but I neither see the error nor does it appear to succeed...

I think this is because as I stated above, MSBuild is not relaying the spec variables properly when the target is invoked. I learned this after a bit of debugging output from the perspective of the CSharp build task code determining what's what, are targets even being invoked, do they see the variables being relayed properly, etc.

So, in summary, I think we are closer to mutual comprehension on the issue, let alone possible root causes, remedial actions, etc, but we're not quite there yet.

[marcpopMSFT]

I can confirm through the binlog that the BumpVersionSpec property is set identically for both Sdk imports. Poking through the code, I think you want to take a look at this line in BumpAssemblyVersions which seems to special case the Microsoft.NET.Sdk: https://github.com/mwpowellhtx/BumpAssemblyVersions/blob/099e32fb9570e5fc1ae501b4ec5230f9567ceed9/src/BumpAssemblyVersions/BumpVersionTask.cs#L306

[mwpowellhtx]

@marcpopMSFT Ah! 💡 Totally fogotten about that line, appreciate the code review. I'll have a closer look at it.

[mwpowellhtx]

Will go ahead and close this one. Appreciate the review once again. We think that is probably the root cause and are pursuing as such.