C#•6mo ago

SDK Project - Duplicate ExcludeFromCodeCoverage in generated file

Hey all, working on an SDK project and running into an interesting issue and I'm not entirely sure how to fix it. When compiling for tests, my test projects get the following exception:

error CS0579: Duplicate 'System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage' attribute

error CS0579: Duplicate 'System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage' attribute

This attribute is being defined in <Project>.AssemblyInfo.cs, a compiled file. Background Initially the LibraryFrameworks value below had targeted netstandard2.1 inline with the rest of the libraries. In order to facilitate phasing out of support of this library, we've done a couple things: 1. In Sdk.props, alongside ExecutableFrameworks and LibraryFrameworks, we've defined a new boolean property TargetNetStandard and removed the netstandard2.1 target from LibraryFrameworks. In order to remain backwards compatibility, TargetNetStandard defaults to true.

<!-- Default targeting configuration -->
<PropertyGroup>
    <ExecutableFrameworks Condition="'$(ExecutableFrameworks)' == ''">net8.0</ExecutableFrameworks>
    <LibraryFrameworks Condition="'$(LibraryFrameworks)' == ''">net6.0;net7.0;$(ExecutableFrameworks)</LibraryFrameworks>
    <TargetNetStandard Condition="'$(TargetNetStandard)' == ''">true</TargetNetStandard>
</PropertyGroup>

<!-- Default targeting configuration -->
<PropertyGroup>
    <ExecutableFrameworks Condition="'$(ExecutableFrameworks)' == ''">net8.0</ExecutableFrameworks>
    <LibraryFrameworks Condition="'$(LibraryFrameworks)' == ''">net6.0;net7.0;$(ExecutableFrameworks)</LibraryFrameworks>
    <TargetNetStandard Condition="'$(TargetNetStandard)' == ''">true</TargetNetStandard>
</PropertyGroup>

1. In Sdk.Targets, the second TargetFrameworks definition was added which adds the netstandard2.1 target alongside the standard library frameworks.

<!--
    Fallback targeting properties - VS sets for DesignTime builds only TargetFramework
    but requires information about all TargetFrameworks
-->
<PropertyGroup Condition="'$(TargetFrameworks)' == ''">
    <!--suppress MsbuildTargetFrameworkTagInspection -->
    <TargetFrameworks>$(LibraryFrameworks)</TargetFrameworks>

    <!--suppress MsbuildTargetFrameworkTagInspection -->
    <TargetFrameworks Condition="'$(TargetNetStandard)' == true">netstandard2.1;$(LibraryFrameworks)</TargetFrameworks>

    <!--suppress MsbuildTargetFrameworkTagInspection -->
    <TargetFrameworks Condition="'$(OutputType)' == 'Exe'">$(ExecutableFrameworks)</TargetFrameworks>
</PropertyGroup>

<!--
    Fallback targeting properties - VS sets for DesignTime builds only TargetFramework
    but requires information about all TargetFrameworks
-->
<PropertyGroup Condition="'$(TargetFrameworks)' == ''">
    <!--suppress MsbuildTargetFrameworkTagInspection -->
    <TargetFrameworks>$(LibraryFrameworks)</TargetFrameworks>

    <!--suppress MsbuildTargetFrameworkTagInspection -->
    <TargetFrameworks Condition="'$(TargetNetStandard)' == true">netstandard2.1;$(LibraryFrameworks)</TargetFrameworks>

    <!--suppress MsbuildTargetFrameworkTagInspection -->
    <TargetFrameworks Condition="'$(OutputType)' == 'Exe'">$(ExecutableFrameworks)</TargetFrameworks>
</PropertyGroup>

Expected Behavior This should in theory create behavior identical to the original - unless the user opts out by setting <TargetNetStandard>false</TargetNetStandard>, the default set of target frameworks should include netstandard2.1;net6.0;net7.0;net8.0 (when it's a library type and not an executable type). If the user specifies false, then the netstandard2.1 target should be excluded. Actual Behavior JIT building (when saving changes made to Skd.targets) appears to work properly, and Rider shows that my test library TargetNetStandardFalse appears to update its targets correctly to indicate that it is no longer targeting netstandard2.1. However, running dotnet build with either debug or release targets results in the duplicate attribute exception, which prevents tests from running. Deleting obj/bin folders has no effect on this behavior, except that it will change which test project receives the error. I imagine this is just dependent on the order the projects are discovered and built rather than some sort of phantom shifting error. Does anyone know why this is happening or how to fix it?

0 Replies

No replies yetBe the first to reply to this messageJoin

Gaming

Programming

SDK Project - Duplicate ExcludeFromCodeCoverage in generated file