Search code examples
visual-studiomsbuild.net-standardcsprojdotnet-sdk

.Net class library compilation error on build machine


I have a SDK styled .Net class library which compiles properly on my local machine, however fails on build server.

The contents of .csproj are

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

  <PropertyGroup>
    <TargetFrameworks>net35;net40;netstandard1.0</TargetFrameworks>
    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
    <Version>1.5.6</Version>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
  </PropertyGroup>

</Project>

The error displayed is: NETSDK1045: The current .NET SDK does not support targeting .NET Standard 4.0. Either target .NET Standard 2.1 or lower, or use a version of the .NET SDK that supports .NET Standard 4.0

I have .NET Core 3.1.113 installed on build server and .NET 5 installed on local machine.

Note: If I remove netstandard1.0 from TargetFrameworks then build succeeds on both the machines. However I want my library to target .net standard 1.0 as well.

I cannot understand why v4.0 is treated as .NET Standard 4.0 on build server. Can anyone let me know what the problem might be?


Solution

  • Remove the following line from your .csproj file:

    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
    

    This overrides the version value that the SDK infers from TargetFramework which will interfere with your definition of net3.5 and so on - you were actually building .NET Framework 4.0 twice and then override netstandard1.0 to .NET Standard (inferred TargetFrameworkIdentifier) to 4.0. Newer versions of the SDK may have different inference logic which may be a difference between 3.1 and 5.0 SDKs but this is an error in the csproj nonetheless.

    If your build logic relies on TargetFrameworkVersion being defined in the project I suggest you try to change your build logic - this is VERY DANGEROUS to have in a modern csproj file where you rely on TargetFramework and TargetFrameworks (plural). You can also try to move it into a separate <PropertyGroup> with an always-fals-condition (e.g. <PropertyGroup Condition="'$(ThisIsToWorkAroundBuildScripts)' == 'True'">)