`Should().BeEquivalentTo()` show different error message between Debug and Release

Description

We compile and launch unit test libraries with the release configuration and x64 platform. After upgrading FluentAssertions from 4.19.2 to 6.5.1 (the latest), we noticed that Should().BeEquivalentTo() gives different error messages while compare classes with properties. Let’s look at the following example:

• Let ClassWithProperty be a class containing one property IntProperty:

public sealed class ClassWithProperty
{
    public ClassWithProperty(int value)
    {
        IntProperty = value;
    }
    public int IntProperty { get; }
}

• The unit test CompareClassWithPropertyObjects compare two objects of type ClassWithProperty, with different property values.

[Test]
public void CompareClassWithPropertyObjects()
{
   //Arrange
    var actual = new ClassWithProperty(1);
    var expected = new ClassWithProperty(2);
    
    //Assert
    actual.Should().BeEquivalentTo(expected);
}

Expected behavior:

Expected property actual.IntProperty to be 2, but found 1.

With configuration:
- Use declared types and members
- Compare enums by value
- Compare tuples by their properties
- Compare anonymous types by their properties
- Compare records by their members
- Match member by name (or throw)
- Be strict about the order of items in byte arrays
- Without automatic conversion.

Actual behavior:

Here, it outputs the }}}, instead of the name of the actual object.

Expected property }}}.IntProperty to be 2, but found 1.

With configuration:
- Use declared types and members
- Compare enums by value
- Compare tuples by their properties
- Compare anonymous types by their properties
- Compare records by their members
- Match member by name (or throw)
- Be strict about the order of items in byte arrays
- Without automatic conversion.

Versions

• .NET : .NET Core 3.1 and .NET 4.7.1
• NUnit : 3.12.0 (I tried also the the version 3.13.1, It gives the same results).
• FluentAssertions : 6.5.1
• Configuration : Release
• Platform : x64

Note that it works totally fine in Debug configuration.

[jnyrup]

I did a related analysis in https://github.com/fluentassertions/fluentassertions/issues/1781#issuecomment-1016784748

[dennisdoomen]

As is documented here, you need to run your tests in Debug mode for FA to be able to extract the variable from the stack trace. Otherwise the compiler will optimize those details away. However, it should fall back to using a generic name, so technically it’s a little bug.