Use Sdks assembly Level Attributes for supported and unsupported platforms.

[Anipik]

We are no longer removing the platform from the targetFrameworkString for net5.0 and above, this results in sdk adding
SupportedOSPlatformAttribute & TargetPlatformAttribute to the assemblyInfo file. This conflicts with the attributes that we are adding on the api level.

We should define a repo wide policy going forward.

There is currently no flag in the sdk to disable writing this attribute while writing this assembly level attriibute. asking sdk team to provide a flag will also be helpful here.

cc @ViktorHofer @ericstj @buyaa-n @safern

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ViktorHofer]

We should define a repo wide policy going forward.

Does this even matter outside of libraries?

[ghost]

Tagging subscribers to this area: @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

[ViktorHofer]

@buyaa-n @jeffhandley what are your thoughts on this? The SDK by default adds the in the top post mentioned attributes. Is there a reason to not have them? Presumably the TargetPlatformAttribute is less of a concern?

[ViktorHofer]

Another thought, are we concerned about the assembly metadata difference: SupportedOSPlatform (dotnet/runtime specific and already shipped with 5.0) vs SupportedOSPlatformAttribute (sdk style)?

[buyaa-n]

The SDK by default adds the in the top post mentioned attributes. Is there a reason to not have them?

The reason for not having them is false positives mentioned in this issue, I have no good way (non-hack like) of handling those, the question if it could happen outside of runtime, if not i thinke its just better to keep disabling the sdk logic cc @terrajobst

Presumably the TargetPlatformAttribute is less of a concern?

I don't think there is a concern, the analyzer not using that attribute at all

[buyaa-n]

I think we should reenable SupportedOSPlatformAttribute attributes added by sdk, most of the warning are found in Browser build which i think is the only target we should disable/remove adding the attribute. The details how to handle the warnings introduced are commented here. By enabling the sdk attribute back

• We will have the attribute for windows build from sdk, which we added to suppress warnings on windows build

  runtime/eng/versioning.targets

  Lines 26 to 29 in 059e6bb

  	<ItemGroup Condition="('$(IsWindowsSpecific)' == 'true' or '$(TargetsWindows)' == 'true') and '$(IsTestProject)' != 'true'">
  	<AssemblyAttribute Include="System.Runtime.Versioning.SupportedOSPlatform">
  	<_Parameter1>windows</_Parameter1>
  	</AssemblyAttribute>

• We will have the attribute for other build targets like linux, ios etc. For now we have no any APIs attributed with those platforms but they are coming soon, so having corresponding attributes added by MSBuild would help with seeing warning for existing platform inconsistency and suppress warnings for proper usage of platform specific APIs in runtime repo

[buyaa-n]

@ViktorHofer @Anipik I see the TFM targets platforms other than windows is not really working, for non-runtime env, for example with simple console app i cannot use Browser or ios or Linux, Android platforms as a target. The error message: C:\Program Files\dotnet\sdk\5.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(109,5): error NETSDK1139: The target platform identifier iOS was not recognized. How/why it is able to work in runtime?

[buyaa-n]

Never mind i see the new identifiers added here

runtime/eng/targetframeworksuffix.props

Lines 8 to 12 in 805e288

	<PropertyGroup Condition="'$(TargetFrameworkSuffix)' != '' and '$(TargetFrameworkSuffix)' != 'windows'">
	<TargetPlatformIdentifier>$(TargetFrameworkSuffix)</TargetPlatformIdentifier>
	<TargetPlatformVersion>0.0</TargetPlatformVersion>
	<TargetPlatformMoniker>$(TargetFrameworkSuffix),Version=$(TargetPlatformVersion)</TargetPlatformMoniker>
	</PropertyGroup>

[Anipik]

@buyaa-n is this still an issue ?

[buyaa-n]

There is nothing more left until dotnet/sdk#14836 implemented and using that feature for disabling TFM attribute in test projects