Code Metrics data is not calculated

[bcollamore]

Analyzer

CodeMetrics

Analyzer source

NuGet Package: Microsoft.CodeAnalysis.Metrics

Version: 3.3.3 (& 3.3.4-beta1.22362.3/latest)

Describe the bug

Metrics file is produced with default values rather than actual values. (See below.)

Steps To Reproduce

Standard Code Metrics instructions

Expected behavior

A complete metrics.xml file produced.

Actual behavior

An essentially empty metrics.xml file is produced, e.g.:

<?xml version="1.0" encoding="utf-8"?>
<CodeMetricsReport Version="1.0">
  <Targets>
    <Target Name="MyProject">
      <Assembly Name="MyProject.csproj, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null">  [Also note the empty version - it should not be.]
        <Metrics>
          <Metric Name="MaintainabilityIndex" Value="100" />
          <Metric Name="CyclomaticComplexity" Value="0" />
          <Metric Name="ClassCoupling" Value="0" />
          <Metric Name="DepthOfInheritance" Value="0" />
          <Metric Name="SourceLines" Value="0" />  [Note incorrect values]
          <Metric Name="ExecutableLines" Value="0" />
        </Metrics>  [Note children nodes missing]
      </Assembly>  
    </Target>
  </Targets>
</CodeMetricsReport>

Additional context

• The problem is observed starting with VS2022 (17.3?), when running via the Nuget package
• The problem does not occur when running Metrics.exe directly, regardless of which version of Visual Studio that Metrics.exe or the project-under-analysis is compiled against.

Running in a debugger revealed that the call to workspace.OpenProjectAsync has this Diagnostic property (when run via msbuild and the Nuget Package):

Msbuild failed when processing the file '<redacted>\MyProject.csproj' with message: Method not found: 'System.ReadOnlySpan`1<Char> Microsoft.IO.Path.GetFileName(System.ReadOnlySpan`1<Char>)'.

This led me to this version update of System.Memory.

The problem is that newer versions of msbuild use a newer version of System.Memory that has a breaking change. When the Metrics Task is run (as defined in the CodeMetrics Nuget Package), it launches Metrics.exe with an incompatible version of the DLL.

To confirm the problem, hacking this:

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Memory" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.1.2" newVersion="4.0.1.2" />
      </dependentAssembly>
    </assemblyBinding>

into the Metrics.exe.config file in the Nuget cache circumvents the issue.

And adding the following PackageReference to Metrics.csproj "fixes" the issue:

    <PackageReference Include="System.Memory" Version="4.5.5" />  

The generic flavor of this problem is discussed here.

An additional suggestion is to update the CodeMetrics documentation to consider having CI/CD pipelines rely on Metrics.exe directly in order to avoid this generic problem.

[mavasani]

@bcollamore Thank you for reporting the issue and the detailed analysis. In the past whenever we have encountered such issues, bumping up the MSBuildLocator version in the repo and publishing a new Metrics NuGet package has resolved the issue. Can you please try the same and let us know if that helps?

[mavasani]

roslyn-analyzers/eng/Versions.props

Line 63 in a26d1a2

<MicrosoftBuildLocatorVersion>1.4.1</MicrosoftBuildLocatorVersion>

[bcollamore]

@mavasani I have had mixed success with updating MSBuildLocator, because it traditionally seems to update infrequently. But version 1.5.3 released a month ago, so this is a great idea. But unfortunately, even weirdly, it did not help.

[pachecoke]

Hi @mavasani, was there an update on this issue? For the time being we had to revert to MsBuild 16 to run the code metrics tool for our projects.

[mavasani]

Thanks @pachecoke. Are you able to create a PR to add the above mentioned PackageReference?

<PackageReference Include="System.Memory" Version="4.5.5" />  

[bcollamore]

Hi @mavasani, @pachecoke, pls see linked PR. (This is my first submission to this repo - please pardon any logistical errors.)

[arunchndr]

Tagging @mavasani as PR buddy.

[Youssef1313]

@bcollamore Should this be closed now as fixed with #6183 ?

[bcollamore]

@Youssef1313 yes, it's confirmed fixed in latest beta.

[Youssef1313]

Thank you @bcollamore for confirmation. I'm going to close this as fixed.