Targeting net5.0-windows still causes 'API X is supported on windows' errors

Hello. I have a project migrated from netcoreapp3.1 to net5.0 that references the System.DirectoryServices 5.0.0 nuget. This nuget targets Windows only (the assembly is marked with [assembly: SupportedOSPlatform("windows")]):

So trying to compile that project with TFM net5.0 errors out with CA1416:

error CA1416: 'DirectorySearcher' is supported on 'windows'

According to the documentation for that rule (emphasis mine):

A violation only occurs if the project does not target the supported platform (net5.0-differentPlatform). This also applies to multi-targeted projects. No violation occurs if the project targets the specified platform (net5.0-platformName).

From that I surmised that switching the project file to target net5.0-windows should be enough to compile the project. Unfortunately, this is not the case - I’m still getting the CA1416 violations.

My csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net5.0-windows</TargetFramework>
    <OpenApiGenerateDocuments>false</OpenApiGenerateDocuments>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>..\..\..\build\</OutputPath>
    <TreatWarningsAsErrors>True</TreatWarningsAsErrors>
    <TreatSpecificWarningsAsErrors />
    <PlatformTarget>x64</PlatformTarget>
    <NoWarn>1701;1702;1591</NoWarn>
  </PropertyGroup>

    <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
    <OutputPath>..\..\..\build\</OutputPath>
    <DebugSymbols>true</DebugSymbols>
    <TreatWarningsAsErrors>True</TreatWarningsAsErrors>
    <TreatSpecificWarningsAsErrors />
    <PlatformTarget>x64</PlatformTarget>
    <NoWarn>1701;1702;1591</NoWarn>
  </PropertyGroup>

  ...

</Project>

dotnet build still caused CA1416 errors. When I add [assembly: SupportedOSPlatform("windows")] to the assembly, it compiles correctly. So either the documentation for rule CA1416 is wrong or something is not working correctly with the net5.0-windows TFM. Or I’m missing something crucial here.

Can you please take a look at this?

EDIT

I should have mentioned that I’m using the current GA versions of dotnet 5.0 SDK:

.NET SDK (reflecting any global.json):
 Version:   5.0.100
 Commit:    5044b93829

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19042
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.100\

Host (useful for support):
  Version: 5.0.0
  Commit:  cf258a14b7

.NET SDKs installed:
  3.1.301 [C:\Program Files\dotnet\sdk]
  3.1.402 [C:\Program Files\dotnet\sdk]
  5.0.100-preview.8.20417.9 [C:\Program Files\dotnet\sdk]
  5.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.0-preview.8.20414.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.0-preview.8.20407.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.0-preview.8.20411.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[mareklinka]

I think I managed to trace the issue down. The problem seems to be caused by the fact that we have a shared project (shproj) in our solution and this shared project contains our AssemblyInfo.cs. The .projitems file contains:

<PropertyGroup>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>
<ItemGroup>
    <Compile Include="$(MSBuildThisFileDirectory)AssemblyInfo.cs" />
</ItemGroup>

And this seems to be interfering with the net5.0-windows TFM from marking the assembly as Windows-only. I suspect that the compiler would emit an [assembly: SupportedOSPlatform("windows")] annotation in the AssemblyInfo.cs but this doesn’t work because AI generation is disabled.

This theory seems to be further supported by the following minimal repro: sdk-repro.zip

The repro is a trivial console app with TFM set to net5.0-windows and GenerateAssmeblyInfo set to false. Attempting to compile this results in:

> dotnet build --no-incremental
Microsoft (R) Build Engine version 16.8.0+126527ff1 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
C:\Source\Personal\sdk-repro\Program.cs(10,35): warning CA1416: 'DirectorySearcher' is supported on 'windows' [C:\Source\Personal\sdk-repro\sdk-repro.csproj]
  sdk-repro -> C:\Source\Personal\sdk-repro\bin\Debug\net5.0-windows\sdk-repro.dll

Build succeeded.

C:\Source\Personal\sdk-repro\Program.cs(10,35): warning CA1416: 'DirectorySearcher' is supported on 'windows' [C:\Source\Personal\sdk-repro\sdk-repro.csproj]
    1 Warning(s)
    0 Error(s)

This should work regardless whether I generate an assembly info or create it manually. Otherwise users can get into a situation where they are targeting net5.0-windows and the resulting assembly doesn’t reflect this.

[dsplaisted]

GenerateAssemblyInfo is a big hammer which turns off all (or almost all) of the automatic assembly attribute generation. So I don’t think there’s a good way for us to still generate SupportedOSPlatform attributes when it’s disabled.

I would suggest one of the following for projects:

• Don’t set GenerateAssemblyInfo to false, rather set the individual properties to false which control automatic attribute generation for attributes which are already defined in user source code. Here’s the list of these properties: https://github.com/dotnet/sdk/blob/e0f0a1f4ca0ea465fcac0804a03085731e019e1f/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.GenerateAssemblyInfo.targets#L26-L39
• Don’t use AssemblyInfo.cs type files at all. Let these attributes be generated automatically, setting their values via MSBuild properties. For example, the Company property determines the value for the automatically generated AssemblyCompanyAttribute. These values can be shared between projects with Directory.Build.props or Directory.Build.targets