TargetFramework.Sdk should ensure an unique TargetFramework property in inner builds

[ViktorHofer]

• Is this issue blocking: no
• Is this issue causing unreasonable pain: no

Porting comments from dotnet/runtime#32300 (comment):

@ViktorHofer: Can we avoid such breaks by coming up with a better pattern which guarantees unique TargetFramework properties in the different inner-builds?

@Anipik: Actually, That was our first experiment. Later on this project we shifted to remove the TargetFrameworkSuffix from TargetFramework bcoz we hit a significant block. I will try to dig up the reason. @ericstj do u remember wht caused us to remove the TargetFrameworkSuffix during the build ?

@ViktorHofer: +1. Yes, please dig up the reason for the change in direction.

@tmat: Please file an issue to fix Microsoft.DotNet.Build.Tasks.TargetFramework.Sdk...

[ericstj]

It was removed because nuget writes conditions depending on $(TargetFramework) to generated props and targets files. We considered a few options to workaround this, but everything hacky/risky. Would be nice if NuGet's generated targets used $(NuGetTargetMoniker) (like assets file resolution does), or some other property, allowing a layer of indirection between the cross-compiling property and the nuget resolution property.

[ViktorHofer]

@rrelyea @nkolev92 do you think @ericstj's ask makes sense and is feasible?

[nkolev92]

This is so inconsistent that I wouldn't feel comfortable giving a definitive response without digging in more.

However, one problem I see is that NuGetTargetMoniker is not guaranteed to be unique, see, NuGet/Home#8388. That's an ask on NuGet to do the opposite of the suggestion.