GitVersion: [Bug] GitVersionInformation.g.cs(12,42): error CS0234 'ExcludeFromCodeCoverageAttribute' does not exist

• I wouldn’t have gone that way, but would have rather defined the attribute itself somewhere in your source code: this should do the trick (until I find, if I can, a proper way to detect a mono build)

Good point, I think it would have been cleaner than using the define.

Could you also elaborate on when exaxtly the build fails? Locally? Only in Azure DevOps? When building or when running the unit tests? Could you share some build log?

It was fails both locally and in Azure DevOps when building.

@ylatuya It’s weird, mono is supposed to support ExcludeFromCodeCoverageAttribute since version 4.8 (here) and Xamarin too since the versions at the bottom of this page

I have tried starting a new Library project from scratch and indeed the attribute is correctly resolved in Mono. The library also compiles correctly adding GitVersionTask to that project. After checking this, I went back to my project and noticed that it was lacking a reference to System (not sure why as vs4mac always adds it by defautl)

To sum up, everything is working as expected. I am sorry for the noise.

We deal with that particular attribute on unsupported platforms in ImageSharp in the following way.

First define your own internal version and type forward it on supported platforms.

#if SUPPORTS_CODECOVERAGE
using System.Runtime.CompilerServices;

[assembly: TypeForwardedTo(typeof(System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute))]
#else
namespace System.Diagnostics.CodeAnalysis
{
    /// <summary>
    /// Specifies that the attributed code should be excluded from code coverage information.
    /// </summary>
    [AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Constructor | AttributeTargets.Method | AttributeTargets.Property | AttributeTargets.Event, Inherited = false, AllowMultiple = false)]
    internal sealed class ExcludeFromCodeCoverageAttribute : Attribute
    {
    }
}
#endif

Then define a custom SUPPORTS_CODECOVERAGE compiler conditional in your Directory.Build.props based on your target frameworks. You can see an example of that here.

https://github.com/SixLabors/ImageSharp/blob/d074b72f33d2d313bd508af49b1bad89a3a31d5a/Directory.Build.props#L47

It works everywhere then.

You can see on what target frameworks it is supported here.

https://apisof.net/catalog/System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute

FWIW, I hit the same error with a VSIX project claiming to target .Net 4.7.2. Workaround was to add a NuGet reference to System.Diagnostics.Tools (4.3.0 in my case). Using GitVersion 5.6.6.

@ENikS

During build of a dll in .Net Standard 2.0 I am getting following error: Unity.Abstractions -> D:\a\abstractions\abstractions\src\bin\Release\netstandard2.0\Unity.Abstractions.dll obj\Release\netstandard1.6\GitVersionInformation.g.cs(12,42): error CS0234: The type or namespace name ‘ExcludeFromCodeCoverageAttribute’ does not exist in the namespace ‘System.Diagnostics.CodeAnalysis’ (are you missing an assembly reference?) [D:\a\abstractions\abstractions\src\Unity.Abstractions.csproj]

As can be seen in the logs you provided us, the issue seems to be rather related to .NET Standard 1.6, not 2.0: if you examine the path in the log, you have netstandard1.6 after obj\Release (there may be something weird in Unity.Abstractions.csproj by the way).

I double-checked in msdn what frameworks support the attribute and indeed it is unknown by .NET Standard < 2.0…

Still, we’ll need some #if on our side, but I honestly expect it to work when ‘really’ targeting .NET Standard 2.0; I’ll go clone your repository and look for this!

Ideas why our tests didn’t discover this, @arturcic?

I think we cover only project targeting .net framework and netcoreapp2.1 and 3.1 in out artifacts testing, because the artifacts can be executed, but netstandard can not

@asbjornu Sure, I’ll have a look at this!

To replicate locally:

• clone Abstractions
• add reference to the the latest GitVersion tool

I guess you will be able to see what build does differently from your tests.