GCHeapDump fails with "Could not load type 'FastSerialization.SerializationConfiguration'" in TraceEvent 3.1.23

[CoreyKaylor]

Summary

After upgrading from Microsoft.Diagnostics.Tracing.TraceEvent version 3.1.13 to 3.1.23, GCHeapDump constructor fails with a TypeLoadException when trying to load .gcdump
files.

Error Message

Error: Could not load type 'FastSerialization.SerializationConfiguration' from assembly 'Microsoft.Diagnostics.FastSerialization, Version=3.1.23.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'.

Environment

• .NET 8.0 application targeting netstandard2.0
• Microsoft.Diagnostics.Tracing.TraceEvent: 3.1.23 (fails) vs 3.1.13 (works)

Steps to Reproduce

1. Create a .NET application that uses Microsoft.Diagnostics.Tracing.TraceEvent 3.1.23
2. Try to instantiate GCHeapDump with a valid .gcdump file:
   var heapDump = new GCHeapDump(filePath); // Throws TypeLoadException

Expected Behavior

GCHeapDump should load the file successfully, as it does with TraceEvent 3.1.13.

Actual Behavior

Application crashes with TypeLoadException looking for FastSerialization.SerializationConfiguration.

Analysis

Based on the #2121, SerializationConfiguration was renamed to SerializationSettings. However, it appears that some internal
code in TraceEvent 3.1.23 is still trying to reference the old SerializationConfiguration class name.

Additional Context

This affects any application that uses GCHeapDump to programmatically analyze .NET heap dumps. The issue appears to be internal to the TraceEvent library during
deserialization of the dump file format.

[brianrob]

I am not able to find any references to SerializationConfiguration anymore. I'm suspicious that you may have some mismatched versions of assemblies here that are causing this error.

@copilot, please try to reproduce this error using the repro steps and setup above. Rather than using a PackageReference to 3.1.23, just reference the TraceEvent csproj via a ProjectReference. Report back on whether you're able to reproduce this behavior or not.

[CoreyKaylor]

I went back and dug in further and it looks like it was because the project also uses another package Microsoft.Diagnostics.Monitoring.EventPipe 8.0.532401 which is published to an Azure feed and not the main nuget.org feed. That is likely where the conflict is coming from now, which makes more sense.

[brianrob]

Thanks @CoreyKaylor. Yes, you may be ending up with a different version of TraceEvent than expected.