[Improvement] GitVersion generated F# code should not participate in code coverage

[odalet]

Altough some work was already done addressing this issue in the general case in #2305, this is not enough to completely get rid of unwanted not-covered code in the F# case.

Detailed Description

#2305 solved the issue of having generated code counted in code coverage (obviously as not covered) by decorating the generated GitVersionInformation class with the ExcludeFromCodeCoverage attribute.

However, the F# compiler generates additional types when compiling a module. Here is what ILSpy gives us when examining an F# assembly:

This $GitVersionInformation type was generated by the compiler, and unfortunately it does not retain the attributes of its source type.

In order to not be polluted by these generated types during code coverage analysis, having the compiler not generate these types is one way to go. By having the F# module replaced by a class with static members, it appears we can achieve this goal. See the implementation section for details.

Possible Implementation

Here is what the generated F# class could look like:

namespace global

[<AbstractClass; Sealed>]
[<global.System.Runtime.CompilerServices.CompilerGenerated>]
[<global.System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage>]
type GitVersionInformation =
    
    static member Major 
        with [<global.System.Runtime.CompilerServices.CompilerGenerated; global.System.Diagnostics.DebuggerNonUserCode>] get() = "1"
    
    static member Minor
        with [<global.System.Runtime.CompilerServices.CompilerGenerated; global.System.Diagnostics.DebuggerNonUserCode>] get() = "2"
    
    static member Patch
        with [<global.System.Runtime.CompilerServices.CompilerGenerated; global.System.Diagnostics.DebuggerNonUserCode>] get() = "3"

Notes:

• The namespace global is needed: F# does not like the class being in an not-explicitely set namespace.
• The pair of attributes in front of each getter is very verbose, but I added them in order to have the code generated by the F# compiler as close as possible to the module-based one.
• Generating this implies both a modification of the template and of the logic that fills the template, but it seems not that difficult.

Compatibility concerns

Similarly to issue #2310 I wondered if that was going to be a breaking change. Well it seems it is not, at least from a C# consumer perspective (I'm not sure if there is special semantics in F# that would work with a module and not with a class):

Both the current module-based and the proposed templates generate the same result when decompiled with ILSpy; something like that:

// GitVersionInformation
using Microsoft.FSharp.Core;
using System.Diagnostics;
using System.Runtime.CompilerServices;

[AbstractClass]
[Sealed]
[CompilerGenerated]
[CompilationMapping(/*Could not decode attribute arguments.*/)]
public static class GitVersionInformation {
	public static string Major {
		[CompilerGenerated, DebuggerNonUserCode]
		get { return "0"; }
	}

	public static string Minor {
		[CompilerGenerated, DebuggerNonUserCode]
		get { return "1"; }
	}

The only remaining difference is that the new template does not produce any $GitVersionInformation type. This type not existing anymore could be considered a compatibility difference if we are picky, but I honestly doubt anyone would try to access this compiler-generated thing by reflection...

A final issue

There is one last issue that I became aware of by examining all the versions of GitVersionInformation. In VB.NET and C#, the members of the class are static fields, but the F# version defines static readonly properties. Not consistent. But here again, choosing fields for the F# version would prove more breaking. Maybe we should live with different implementations of the GitVersionInformation type per source language until the next major version...

Generating nearly identical code at the IL level from the three languages may be possible (I just need to figure out how F# supports fields in classes), but is it desirable right now? And if we were to go down this path, I would favor using readonly properties rather than read/write fields.

[asbjornu]

I think the rationale for doing this is pretty much on par with what I wrote in #2310 (comment). I'm not familiar enough with F# to know what would be considered idiomatic or conventional.

Generating nearly identical code at the IL level from the three languages may be possible (I just need to figure out how F# supports fields in classes), but is it desirable right now? And if we were to go down this path, I would favor using readonly properties rather than read/write fields.

I agree with this design goal. Identical IL across the languages would be ideal. I also think properties are favourable over fields. Changing this would be a breaking change for C# and VB.NET, though. Since the Venn diagram for user of C# + user of GitVersion + does reflection on the GitVersionInformation class is much larger than that for VB.NET, we need to think hard about this one.

Thoughts, @arturcic, @gep13?

[odalet]

OK, then I'll come up with a 'conservative' PR that simply replaces the module with a static class.
I too am not sure the static class is idiomatic (I guess it is not, otherwise, there would be no point for the module construct), however it is not meant as logic code and in any case, reflection code is never very idiomatic.

Concerning the more long term goal of unifying the various generated classes, I can come up with yet another issue for discussion aimed at the next major version.

I think we could aim for similar generated code along with documentation explaining what traits are common and guaranteed to be relied upon (target namespace, properties vs fields, class name...) and what are not (visibility? set of attributes? staticness of the resulting type?) + examples of reflection-based code that would work across all source-languages. Just a thought, maybe that's going too far...

[github-actions]

🎉 This issue has been resolved in version 5.3.6 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀