Future of incompatible-TF checks

[rainersigwald]

I'm separating out an issue that I noticed while testing the fix for dotnet/msbuild#1276 (in the form of dotnet/msbuild#1866 + #993) so we can discuss it without the confusion of the other parts of the change.

In the 1.0 SDK + common targets, projects always ask their references "what framework should I build you for, given that I am TF {x}?". That enables GetNearestTargetFramework to error out if there is no compatible TF in the reference (for example, if a netstandard1.2 project references a netstandard1.5 project).

If we go ahead with my proposal that avoids extra evaluation overhead, we won't be able to preserve this behavior for free, because it requires knowledge of both referring TF and referred TFs--and the only way to pass referring TF down to the reference is by evaluating it with a global property, which is the performance problem we are trying to avoid!

How bad would losing this behavior be?

@nguerrera @livarcocc @AndyGerlicher

[rainersigwald]

I can see a few options:

• Preserve the current behavior
  • ➕ Keeps the incompatible-TF check
  • ➖ Requires evaluating any project that is referenced multiple times, which is inefficent, expecially for C++ projects (which have a targeted mitigation in place now but it's ugly).
• Abandon the checks
  • ➕ Really easy 😇
  • ➖ Loses very nice, valuable information
• Restructure the checks to be on the consuming side, rather than the producing side
  • ➕ Allows more-efficient evaluation
  • ➕ Error messages are vastly improved, because they can specify the referring project + TF and the referred's list of TFs
  • ➖ Implementation is unclear
  • ➖ Requires embedding the compatibility check in common targets, to support the (currently supported) non-SDK-full-framework-project-refers-to-incompatible-SDK-project case.

[rainersigwald]

Discussed this with @livarcocc @dsplaisted @nguerrera and some others on Monday. Consensus is that losing the checks is bad and we shouldn't do that.

One possible implementation of "check on the consuming side" would be to make a new compatibility check, decoupled from its current home in NuGet.

[github-actions]

Due to lack of recent activity, this issue has been labeled as 'stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.

[github-actions]

This issue will now be closed since it has been labeled 'stale' without activity for 30 days.