dotnet test logs "netcoreapp6.0" instead of "net6.0"

[ViktorHofer]

See log here: https://helixre107v0xdeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-39923-merge-aa9b5bbbcfef4b559b/System.Net.Security.Tests/console.7e5e7c45.log?sv=2019-07-07&se=2020-11-01T16%3A25%3A58Z&sr=c&sp=rl&sig=91ls7H2FESnHzB5xwF328nTIAR6ll5m0TAnYPSZOmeA%3D

Using the latest runner: 16.8.0-release-20201009-01.

There is no netcoreapp6.0 TargetFramework. Instead it should be net6.0.

[Sanan07]

@ViktorHofer What is targetFramework in your runsettings?

[ViktorHofer]

I don't specify one, I assumed it's auto-detected.

[Sanan07]

You can look TFM through diag logs. From code I see that TP gets targetFramework from runsettings and then call NuGetFramework.Parse to get exact name for output.

[ViktorHofer]

I assume someone writes that then into the in-memory representation of the .runsettings file. Here is our .runsetttings (we dynamically generate it):

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <RunConfiguration>
    <!-- Directory for test run reports. E.g. trx, coverage etc. -->
    <ResultsDirectory>.\TestResults\</ResultsDirectory>
    <!-- Working directory for test invocation. Results directory can be relative to this. Used by IDEs. -->
    <SolutionDirectory>.\</SolutionDirectory>
    <!-- Degree of parallelization, spawns n test hosts to run tests. -->
    <MaxCpuCount>0</MaxCpuCount>
    <!-- If true, an adapter should disable any test case parallelization. -->
    <DisableParallelization>false</DisableParallelization>
    <!-- If true, an adapter shouldn't create appdomains to run tests. -->
    <DisableAppDomain>false</DisableAppDomain>
    <!-- Filter out failing (wrong framwork, platform, runtime or activeissue) tests -->
    <TestCaseFilter>category!=IgnoreForCI&amp;category!=OuterLoop&amp;category!=failing</TestCaseFilter>
    <DotNetHostPath>F:\workspace\_work\1\s\artifacts\bin\testhost\net6.0-Windows_NT-Debug-x64\dotnet.exe</DotNetHostPath>
    <EnvironmentVariables>
      
    </EnvironmentVariables>
  </RunConfiguration>
  <LoggerRunSettings>
    <Loggers>
      <Logger friendlyName="trx" />
      <Logger friendlyName="html" />
      <Logger friendlyName="console">
        <Configuration>
          <Verbosity>Minimal</Verbosity>
        </Configuration>
      </Logger>
    </Loggers>
  </LoggerRunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <DataCollector friendlyName="XPlat code coverage" enabled="false">
        <Configuration>
          <Include></Include>
          <ExcludeByFile></ExcludeByFile>
          <IncludeDirectory></IncludeDirectory>
          <Format>opencover</Format>
          <SingleHit>false</SingleHit>
          <UseSourceLink>true</UseSourceLink>
          <IncludeTestAssembly>false</IncludeTestAssembly>
        </Configuration>
      </DataCollector>
      <DataCollector friendlyName="blame" enabled="True">
        <Configuration>
          <CollectDump DumpType="Full" />
          <CollectDumpOnTestSessionHang TestTimeout="15min" HangDumpType="Full" />
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

[Sanan07]

What about TFM of dll which you are testing System.Net.Security.Tests.dll?

[nohwnd]

We rely on the Nuget.Frameworks package for doing that conversion, I would look into how the version that is shipped with SDK (because that is where we load it from) behaves. The flow here should be that we look at the assembly metadata (assembly: TargetFramework) and find .NETCoreApp,6.0, then convert it to short TFM for readability, there it probably goes wrong, because the Nuget.Frameworks library does not know about net6.0 and tries to guess the name, based on a pattern. And later the same goes backwards, when it converts netcoreapp6.0 to .NETCoreApp,Version=v6.0

[ViktorHofer]

What about TFM of dll which you are testing System.Net.Security.Tests.dll?

net6.0...

[nohwnd]

@Sanan07 are you going to take this issue? I think there might be a chance that it fixes itself when NuGet.Frameworks 5.8.0 is released and dotnet sdk starts relying on it.

[Sanan07]

I tried to reproduce the issue, but was not successful, so I am not sure, what to do next, cause I do not see any issue with code in TP, it just reads target framework and uses Nuget to convert it. So probably your thoughts are correct, we can wait until Nuget update.