LAMA0086: The analysis of memory retained by compile-time code is complete

Cause

When you build a project with the MetalamaDiagnoseMemoryLeaks MSBuild property set to true, Metalama analyzes the objects that your compile-time code leaves behind and looks for references that would keep a version of the project in memory in the IDE. LAMA0086 is the summary of this analysis. Metalama reports it once per project and target framework, at the end of the analysis, even when it finds nothing. It's a warning so that it's visible in the build output, not because something is necessarily wrong.

In the message:

• <UserCodeCount> is the number of retentions in your own compile-time code. Each of them is also reported as a separate warning, LAMA0085, up to 20 warnings.
• <FrameworkCount> is the number of retentions found only in Metalama's own objects. You can't act on them, and a non-zero count is normal.
• <Completeness> states whether the analysis is complete. The walk of the object graph can be interrupted before the end, in which case the counts are a lower bound. On .NET Framework, which desktop MSBuild uses, the entries of a ConditionalWeakTable can't be enumerated, so objects retained only through such a table aren't reported.
• <ReportPath> is the path of a text file that lists every retention, in both categories, with its full chain of references. The file is written to the FabricRetentionReports subdirectory of the Metalama temporary directory, for instance %TEMP%\Metalama\FabricRetentionReports\MyProject-net8.0.txt, and the next analysis of the same project and target framework replaces it.

This diagnostic is reported only when a dedicated MSBuild property enables an analysis of the object graph, so it can't be shown in an example.

Resolution

This warning doesn't require a fix by itself:

• If <UserCodeCount> is greater than zero, fix the LAMA0085 warnings. Open the report file to see all retentions when there are more than 20.
• If the analysis is incomplete because it ran on .NET Framework, build with the .NET SDK (dotnet build) instead of desktop MSBuild to cover all references.
• When you're done investigating, stop passing the MetalamaDiagnoseMemoryLeaks property. Don't set it in your project file, because the analysis slows down every build.

See also

• Diagnosing memory leaks caused by compile-time code
• MSBuild properties and environment variables
• LAMA0085