Source generator targets (from NuGet packages) not running on unsupported TFMs

[layomia]

The AddNETStandardCompatErrorFileForPackaging target infra to emit a warning for unsupported NuGet package consuming TFMs causes source generator targets (for Roslyn version multitargeting, and for enabling/disabling generators) to get dropped for unsupported TFMs. This is undesirable and can lead to undefined behavior.

PR 9eab1ce fixes this issue for the config binding generator, enforcing that the enabling target runs for all TFMs & also emitting the compat warning for unsupported TFMs. This fix is hardcoded for now. We should also fix it for the other source-generator targets for multi-targeting and disabling, and come up with the right templating across all the targets & packages.

cc @ViktorHofer @ericstj

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The AddNETStandardCompatErrorFileForPackaging target infra to emit a warning for unsupported NuGet package consuming TFMs causes source generator targets (for Roslyn version multitargeting, and for enabling/disabling generators) to get dropped for unsupported TFMs. This is undesirable and can lead to undefined behavior.

PR 9eab1ce fixes this issue for the config binding generator, enforcing that the enabling target runs for all TFMs & also emitting the compat warning for unsupported TFMs. This fix is hardcoded for now. We should also fix it for the other source-generator targets for multi-targeting and disabling, and come up with the right templating across all the targets & packages.

cc @ViktorHofer @ericstj

Author:	layomia
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	8.0.0

[KalleOlaviNiemitalo]

The way Microsoft.Extensions.Configuration.Binder checks target framework compatibility in #84379 does not look compatible with target framework aliases. So even if NuGet/Home#5154 is fixed at the NuGet side, aliases still would not work with this package, unless the consuming project sets the SuppressTfmSupportBuildWarnings property.

I guess fixing that would mean changing

runtime/src/libraries/Microsoft.Extensions.Configuration.Binder/src/buildTransitive/Microsoft.Extensions.Configuration.Binder.targets

Lines 19 to 26 in 5535e31

	<_Microsoft_Extensions_Configuration_Binder_Compatible_TargetFramework
	Condition="$([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'netcoreapp2.0')) AND
	!$([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net6.0'))"
	>net6.0</_Microsoft_Extensions_Configuration_Binder_Compatible_TargetFramework>
	<_Microsoft_Extensions_Configuration_Binder_Compatible_TargetFramework
	Condition="$([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net461')) AND
	!$([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net462'))"
	>net462</_Microsoft_Extensions_Configuration_Binder_Compatible_TargetFramework>

to

            <_Microsoft_Extensions_Configuration_Binder_Compatible_TargetFramework
                Condition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp' AND
                           $([MSBuild]::VersionGreaterThanOrEquals('$(TargetFrameworkVersion)', '2.0')) AND
                           !$([MSBuild]::VersionGreaterThanOrEquals('$(TargetFrameworkVersion)', '6.0'))"
                >net6.0</_Microsoft_Extensions_Configuration_Binder_Compatible_TargetFramework>
            <_Microsoft_Extensions_Configuration_Binder_Compatible_TargetFramework
                Condition="'$(TargetFrameworkIdentifier)' == '.NETFramework' AND
                           $([MSBuild]::VersionGreaterThanOrEquals('$(TargetFrameworkVersion)', '4.6.1')) AND
                           !$([MSBuild]::VersionGreaterThanOrEquals('$(TargetFrameworkVersion)', '4.6.2'))"
                >net462</_Microsoft_Extensions_Configuration_Binder_Compatible_TargetFramework>

Fortunately, [MSBuild]::IsTargetFrameworkCompatible is not used in any other packages from dotnet/runtime.