MissingMethodException on using LoggingAssert Contains

[Dorus]

I updated my xUnit packages today, and got this exception:

System.MissingMethodException: Method not found: 'Void Xunit.Sdk.EqualException..ctor(System.Object, System.Object)'.
   at Xunit.LoggingAssert.Contains(IEnumerable`1 expectedValues, IEnumerable`1 actualValues)
   at Xunit.LoggingAssert.Contains(String key, Object value, IEnumerable`1 actualValues)

on calling this code:

var log = _loggerFactory.Sink.LogEntries.First();
LoggingAssert.Contains("fileName", "bla.txt", log.Properties);

[alefranz]

Thanks for the report, I'll have a look!

[Dorus]

I ended up doing the check with FluentAssertions like this:

    var log = _loggerFactory.Sink.LogEntries.Select(e => e.Properties).Should().BeEquivalentTo(new[] {
      new Dictionary<string, string>
      {
        { "{OriginalFormat}", "File {fileName} is not an xml file." },
        { "fileName", "bla.txt" }
      }
    });

[b-straub]

Same for me 2.4.2 working , 2.5.0 not. Testing on .NET8.0 latest preview with async tests.

[bemayr]

@alefranz Maybe the following can help your investigation a bit:

I just had the same problem while debugging Roslyn Analyzer Tests and found out that between xUnit 2.4.2 and 2.5.0 the public interface of EqualException changed. This diff clearly shows the difference in the constructor, which leads to the MissingMethodException.

For MELT, the problem is in those lines:

MELT/src/MELT.Xunit/LoggingAssert.cs

Lines 53 to 55 in b4fbc54

	throw new EqualException(
	expected: GetString(expectedValues),
	actual: GetString(actualValues));

It looks like

EqualException.ForMismatchedValues(expected, actual)

is the new way to construct such an Exception now.

---

As a comparison the Roslyn Analyzer Testing problem stems from:
https://github.com/dotnet/roslyn-sdk/blob/42ce3944fc4488a7ebfbf1f8d395c66808577d77/src/Microsoft.CodeAnalysis.Testing/Microsoft.CodeAnalysis.Testing.Verifiers.XUnit/EqualWithMessageException.cs#L12-L16

[alefranz]

Released 0.9.0.
Any feedback is appreciated.

Thanks for the investigation @bemayr .
I went the easy route for now and built the base exception, manually crafting the message.
Given the discussion on dotnet/roslyn-sdk#1099, it seems like the best solution is to drop the dependency to the assert package. I have some refactoring in progress, so will consider dropping it as part of that.