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

[ENikS]

Describe the bug

Latest version 5.3.6 fails in .Net Standard 2.0 builds.

Expected Behavior

Expected build to not fail. Version 5.3.5 builds all frameworks correctly.

Actual Behavior

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]

The generated file fails on line 12:

```C#
//------------------------------------------------------------------------------
//
// This code was generated by a tool.
// GitVersion
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
//
//------------------------------------------------------------------------------

[global::System.Runtime.CompilerServices.CompilerGenerated]
[global::System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage] <-- This line fails in NETSTANDARD2_0
static class GitVersionInformation
{
public static string Major = "6";
public static string Minor = "0";
public static string Patch = "0";
. . .
}
```

Possible Fix

Reverted to previous version for now

Steps to Reproduce

For more information please follow this link and examine Build step.

Context

I am using GitVerion tool in CI builds. The library is added to projects during CI steps

Your Environment

netstandard2.1;netstandard2.0;netstandard1.6;netcoreapp3.0;netcoreapp2.0;netcoreapp1.0;net48;net47;net46;net45;net40

• Version Used: 5.3.6
• Link to your project: https://github.com/unitycontainer/abstractions
• Link to your CI build (if appropriate): https://github.com/unitycontainer/abstractions/blob/release/6.0.0/.github/workflows/cd-flow.yml

[asbjornu]

This comes from #2306. I suppose we need to do some #if-ing here to only add this attribute for compatible targets. Weird that we don't discover this in our tests, I have to say.

@odalet, is this something you can assist with fixing?

[asbjornu]

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

[ENikS]

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.

[odalet]

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

[arturcic]

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]

Ok, so to discover this we would need one project for each of our target platforms that reference GitVersion.Core as a library?

[odalet]

@ENikS

During build of a dll in .Net Standard 2.0 I am getting following error:
Unity.Abstractions -> D:aabstractionsabstractionssrcbinReleasenetstandard2.0Unity.Abstractions.dll
objReleasenetstandard1.6GitVersionInformation.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:aabstractionsabstractionssrcUnity.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 _objRelease_ (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!

[odalet]

So, a quick fix could look like this:

#if NETFRAMEWORK || (NETCOREAPP && !NETCOREAPP1_0 && !NETCOREAPP1_1) || (NETSTANDARD && !NETSTANDARD1_0 && !NETSTANDARD1_1 && !NETSTANDARD1_2 && !NETSTANDARD1_3 && !NETSTANDARD1_4 && !NETSTANDARD1_5 && !NETSTANDARD1_6)
[global::System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage]
#endif

It's a bit ugly, but works (at least across .NET fx, .NET Core and .NET Standard - maybe we'll need more of this if we are to target Xamarin, old portable libs, Silverlight or whatever weird target we'll come up with).

Then I wonder, maybe it would be better to detect the target framework at generation time. For now, I suppose I'll simply propose the code above for a quick fix.

[JimBobSquarePants]

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.

```c#

if SUPPORTS_CODECOVERAGE

using System.Runtime.CompilerServices;

[assembly: TypeForwardedTo(typeof(System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute))]

else

namespace System.Diagnostics.CodeAnalysis
{
///

/// Specifies that the attributed code should be excluded from code coverage information.
///

[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

[odalet]

@JimBobSquarePants Yes, I knew some types are "duck-typing" detected by .NET and was wondering whether this applied to this attribute as well, but didn't have time to explore this further.

I really like the #else part. However, I'm not so sure about the way you define the #if value in our case:

• your solution is cleaner than mine but it needs to be exhaustive across all supported targets.
• with my - arguably less readable - way, I managed to limit the number of tests (anything .NET fx is ok, anything .NET Core and not 1.0 or 1.1 is ok...).

Anyway that's a great suggestion (I expected no less from _ImageSharp_ 👍) and very helpful!

PS: Still one question though. What is the TypeForwardedTo needed for? wouldn't defining the type in a #if !SUPPORTS_CODECOVERAGE be enough?

[github-actions[bot]]

:tada: This issue has been resolved in version 5.3.7 :tada:
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot :package::rocket:

[ylatuya]

I can reproduce this same issue with GitVersion 5.5.0 in a library project targeting .Net Framework v4.8 using Mono 6.12.0.93.

Mono does not seems to have the ExcludeFromCodeCoverage attribute implemented.

[odalet]

@ylatuya I've had a look at your repository and in particular to this hack of yours. I have zero experience with building Xamarin code so I wouldn't know where to start in order to detect a mono compiler and the lack of the ExcludeFromCodeCoverage attribute in this case.

Anyway, I can see you forced the definition of NETSTANDARD1_6 constant in order for the missing attribute to be generated. Two remarks:

• You only define the constant for Debug builds. I suppose your release builds will keep failing unless you define it for Release builds as well
• 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)

If you'd like to try my last suggestion, simply copy/paste the code below somewhere in your project:

namespace System.Diagnostics.CodeAnalysis
{
    [global::System.AttributeUsage(
        global::System.AttributeTargets.Assembly |
        global::System.AttributeTargets.Class |
        global::System.AttributeTargets.Struct |
        global::System.AttributeTargets.Constructor |
        global::System.AttributeTargets.Method |
        global::System.AttributeTargets.Property |
        global::System.AttributeTargets.Event,
        Inherited = false, AllowMultiple = false)]
    internal sealed class ExcludeFromCodeCoverageAttribute : global::System.Attribute { }
}

When I find some time, I'll clone your repository and try to build it and see if I can come up with something better.

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?

[odalet]

@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

[ylatuya]

• 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.

[odalet]

Seems we're all good then!