postsharp / metalama.samples Goto Github PK

From https://doc.metalama.net/examples/caching/caching-4, see screenshot below. The text after the codeblock starts "The first line defines an error kind" - but there is no such error definition in the code block. It looks like the definition of _error is missing.

[Cloneable] does not support children with explicit implementation of ICloneable - it just assumes that if ICloneable is implemented by a child, the accessible method Clone() must exist and must be the implementation of ICloneable.Clone(). While this keeps the example a bit simpler, this restriction is not mentioned in the documentation (as far as I can see). Also, it might be useful to demonstrate a use pattern for INamedType.TryFindImplementationForInterfaceMember and IMember.IsExplicitInterfaceImplementation which do not appear to be demonstrated anywhere in this repo at present.

My experimental fix for this modifies CloneImpl as follows:

        var typeOfICloneable = (INamedType) TypeFactory.GetType( typeof( ICloneable ) );
        var methodOfIClonableClone = typeOfICloneable.Methods.Single( m => m.Name == "Clone" );

        foreach ( var field in clonableFields )
        {
            var fieldType = (INamedType) field.Type;

            fieldType.TryFindImplementationForInterfaceMember( methodOfIClonableClone, out var interfaceMethodImpl );

            if ( interfaceMethodImpl is { IsExplicitInterfaceImplementation: true } )
            {
                field.With( clone ).Value = meta.Cast( fieldType, meta.Cast( typeOfICloneable, field.Value )?.Clone() );
            }
            else
            {
                field.With( clone ).Value = meta.Cast( fieldType, field.Value?.Clone() );
            }
        }

See below two examples like:

[!metalama-file CloneableAttribute.cs from="BuildAspect1:Start" from="BuildAspect1:End"]

From context, these don't render as intended, likely because the syntax should be from=... to=... (just a guess).

https://github.com/postsharp/Metalama.Samples/blob/74858ef6084329274301ae7da64ebfd281b4299a/examples/clone/clone-1/README.md?plain=1#LL31C39-L31C88

https://github.com/postsharp/Metalama.Samples/blob/74858ef6084329274301ae7da64ebfd281b4299a/examples/clone/clone-1/README.md?plain=1#LL47C39-L47C88

testing hooks

The implementation of AddEmptyCloneMembersAspect fails to compile because it does not implement BuildEligibility method.

Hi!

I am creating a custom log attribute, and I run into an error when tried to convert parameter object to json. I have the following lines in my code:

    protected InterpolatedStringBuilder BuildInterpolatedString()
    {
        var stringBuilder = new InterpolatedStringBuilder();

        stringBuilder.AddText(meta.Target.Method.Name);

        stringBuilder.AddText("(");

        var i = meta.CompileTime(0);

        foreach (var prop in meta.Target.Parameters)
        {
            var comma = i > 0 ? ", " : "";

            if (prop.RefKind == RefKind.Out)
            {
                stringBuilder.AddText($"{comma}{prop.Name} = <out> ");
            }
            else
            {
                
                stringBuilder.AddText(prop.Name);
                stringBuilder.AddText(" : ");
                var json = System.Text.Json.JsonSerializer.Serialize(prop.Value);
                stringBuilder.AddText(json);
                //stringBuilder.AddExpression(prop.Value);
            }

            i++;
        }

        stringBuilder.AddText(")");

        return stringBuilder;
    }

On run I get the following error: CS0234: The type or namespace name 'Json' does not exist in the namespace 'System.Text' (are you missing an assembly reference?)

When I inspect the converted code I found out that the System.Text.Json not got imported it is missing!
The code will not compile even if I write the full namespace like:
var json = System.Text.Json.JsonSerializer.Serialize(prop.Value);

In each of these examples you add the following check:

// Determine if tracing is enabled.
var isTracingEnabled = logger.IsEnabled( LogLevel.Trace );

Whilst this works in your samples it doesn't work that well in real life, especially with different logging providers (which when all said and done is the main point behind using ILogger in the first place).

Having spent a while playing around with this and run numerous experiments I've come to the conclusion that the following is a more versatile implementation which not only preserves the ability to swap providers but also makes it very easy to make use of settings files to determine the degree of logging that you actually want to occur.

//add a check to see if we do actually want to do any logging at all
var isTracingEnabled = this.logger.IsEnabled(LogLevel.Trace) |
this.logger.IsEnabled(LogLevel.Debug) |
this.logger.IsEnabled(LogLevel.Information);