MSB4181 vis-a-vis custom MSBuild task targets

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

[mwpowellhtx]

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

[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