Generated code is only supported on .NET 7 and newer

[Sewer56]

Context

TVO generates dead code that is unfriendly towards runtimes that are older than .NET 7.

Explanation

TVO, by default generates types for the following augments, regardless of whether the features are used or not:

• DefaultEqualityComparerAugment.g.cs
• DefaultValueAugment.g.cs
• EfCoreAugment.g.cs
• JsonAugment.g.cs
• IDefaultEqualityComparer.g.cs
• IDefaultValue.g.cs
• IValueObject.g.cs

The first 4 can only be used on .NET 5 and above due to ExcludeFromCodeCoverage with Justification.

/// <summary>
/// Augment to enable JSON support by generting a JSON converter for the value object.
/// </summary>
/// <remarks>
/// This only supports <c>System.Text.Json</c> at the moment.
/// </remarks>
[global::System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage(Justification = "Auto-generated")]
internal sealed class JsonAugment : global::TransparentValueObjects.IAugment { }

The last 3 can only be used on (.NET 6 with LangVersion==preview) or .NET 7+, due to use of static abstract.

/// <summary>
/// Represents the interface for <see cref="global::TransparentValueObjects.DefaultEqualityComparerAugment"/>
/// with members that the consumer has to implement to support the augment.
/// </summary>
internal interface IDefaultEqualityComparer<out TValueObject, TInnerValue>
    where TValueObject : global::TransparentValueObjects.IValueObject<TInnerValue>
    where TInnerValue : notnull
{
    /// <summary>
    /// Gets a equality comparer for the inner value type to be used by default.
    /// </summary>
    public static abstract global::System.Collections.Generic.IEqualityComparer<TInnerValue> InnerValueDefaultEqualityComparer { get; }
}

Expected Outcome

• Unused code is not generated.

  • This code still ends up in the DLL if not trimmed, increasing size.

• ExcludeFromCodeCoverage w/ Justification is used on .NET 5+ only. Older runtimes use no justification.

Alternatively source generator warns if TargetFramework is set too low.

Supporting Evidence

When no augments used.

[erri120]

The source generator uses the post-init stage to create all the augments and base types:

TransparentValueObjects/src/TransparentValueObjects/ValueObjectIncrementalSourceGenerator.cs

Lines 17 to 34 in cc4031e

	initContext.RegisterPostInitializationOutput(postInitContext =>
	{
	// Core
	postInitContext.AddSource(ValueObjectAttribute.HintName, ValueObjectAttribute.SourceCode);
	postInitContext.AddSource(IValueObject.HintName, IValueObject.SourceCode);
	postInitContext.AddSource(IAugment.HintName, IAugment.SourceCode);
	postInitContext.AddSource(IAugmentWith.HintName, IAugmentWith.Generate());
	// Augments
	postInitContext.AddSource(Augments.DefaultValueAugment.HintName, Augments.DefaultValueAugment.SourceCode);
	postInitContext.AddSource(Augments.DefaultEqualityComparerAugment.HintName, Augments.DefaultEqualityComparerAugment.SourceCode);
	postInitContext.AddSource(Augments.JsonAugment.HintName, Augments.JsonAugment.SourceCode);
	postInitContext.AddSource(Augments.EfCoreAugment.HintName, Augments.EfCoreAugment.SourceCode);
	// Augment interfaces
	postInitContext.AddSource(AugmentInterfaces.IDefaultValue.HintName, AugmentInterfaces.IDefaultValue.SourceCode);
	postInitContext.AddSource(AugmentInterfaces.IDefaultEqualityComparer.HintName, AugmentInterfaces.IDefaultEqualityComparer.SourceCode);
	});

By design, this stage doesn't have any dependencies, so it will always output the same code regardless of the context. As such, I won't be changing the generator to conditionally output these kinds of sources.

[erri120]

As for compatibility, I think I'll follow the .NET Support Policy and try to support .NET 6, 7, and 8.

[Sewer56]

As for compatibility, I think I'll follow the .NET Support Policy and try to support .NET 6, 7, and 8.

Misc Note: That policy also covers Framework which is considered as 'supported', hence why MSFT libraries still ship netstandard 2.0. (Much to some library authors' dismay)

[erri120]

As for compatibility, I think I'll follow the .NET Support Policy and try to support .NET 6, 7, and 8.

Misc Note: That policy also covers Framework which is considered as 'supported', hence why MSFT libraries still ship netstandard 2.0. (Much to some library authors' dismay)

That's part of the .NET Framework Support policy. I meant the .NET and .NET Core policy, which only covers the latest LTS and STS releases.

[Sewer56]

Got a bit busy there, sorry for the wait.

To clarify. The note I was making that if the point is to 'do what Microsoft does', then that means supporting Xamarin (Mono) and Framework. So netstandard2.0 for libraries.

I know you (probably) don't want to do that, but it felt necessary to point out.