Fix sequencing of TargetFrameworkSuffix stripping#4993
Conversation
Hooking into CollectPackageReferences for stripping the TargetFrameworkSuffix is a big hammer and unnecessary as the exact targets that read the TargetFrameworks value are _GetRestoreTargetFrameworksOutput;_GetRestoreTargetFrameworksAsItems. Those targets are always invoked as part of the _GenerateRestoreGraph on which we hook the attaching of the TargetFarmeworkSuffix then.
ViktorHofer
changed the title
|
It's unfortunate that have to use private targets here. I'm OK if this unblocks you. An alternative, if feasible, would be to do something similar to TargetFramework. If we can be sure that everything that needs to understand the suffixed TargetFrameworks is owned by us (this I'm not sure of) then we could just assign the suffixed TargetFrameworks to our own property, and do the stripping as part of evaluation and never undo it. |
|
Hopefully we can remove this stuff after the new tfm work |
Yeah, that's possible. The new TFMs have the right precedence X-Y compatible with X, so even if we map X-Y to something different (TFM=X, RID=Y) than the actual SDK (TFM=X-Y) I suspect we can make it work. 🤞 |
3 participants
Hooking into
CollectPackageReferencesfor stripping theTargetFrameworkSuffixis a big hammer and unnecessary as the exact targets that read the TargetFrameworks value are_GetRestoreTargetFrameworksOutput;_GetRestoreTargetFrameworksAsItems. Those targets are always invoked as part of the _GenerateRestoreGraph on which we hook the attaching of the TargetFarmeworkSuffix then.Keeping the hook on
CollectPackageReferencesdoesn't guarantee that attaching of the Suffix later as that target is also called outside of the Restore phase. This fixes that and allows P2P OS-specific references.