sdk: 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]

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 15
Comments: 20 (6 by maintainers)

Links to this issue

c# - Auto Versioning in Visual Studio 2017 (.NET Core) - Stack Overflow

Most upvoted comments

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.

mareklinka on Nov 11, 2020

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

dsplaisted on Apr 28, 2021

@mareklinka Thank you, the following worked for me:

#if NET5_0
[assembly: System.Runtime.Versioning.SupportedOSPlatform("windows")]
#endif

yevgeni-zolotko on Nov 13, 2020

@kirsan31 I’ve added just the following and only the following [assembly: System.Runtime.Versioning.SupportedOSPlatform("windows7.0")]

be sure not to add after adding [assembly: System.Runtime.Versioning.SupportedOSPlatform("windows")]

Adding both only removes only the windows warning but not the Windows 7.0 warning. Adding the first removes both.

dove on Jan 14, 2021

#if NET5_0
[assembly: System.Runtime.Versioning.SupportedOSPlatform("windows")]
#endif

removes only CA1416: xxx is supported on 'windows' messages. And what to do with dozens of CA1416 xxx is supported on 'Windows' 7.0 and later from all user controls that target net5.0-windows?

kirsan31 on Dec 17, 2020

I was able to get this to go away by moving all my [assembly:] to csroj using <AssemblyAttribute>. Unfortunately the parameters for those need to be strings (out of the box anyway: https://github.com/dotnet/msbuild/issues/2281#issuecomment-748082402). For right now I deleted the [assembly: ComVisible] attributes from my project that VS put there by default. It would be really nice if this issue was fixed.

ekgurney14 on Dec 18, 2020

@yevgeni-zolotko Until this is properly resolved, you can work around the issue by putting [assembly: SupportedOSPlatform("windows")] into your shared AssemblyInfo.cs. This should get rid of the warning.

mareklinka on Nov 13, 2020