How is System.Core.dll's version updated depending on the dotnet SDK/runtime?

Josip Grgić 20 Reputation points

Locally, I have downloaded the dotnet 6.0.416 SDK that contains the 6.0.24 runtimes.

When I build my solution and navigate to the bin/x64/Debug/net6.0/refs folder, find the System.Core.dll file, and check its properties (right-click + properties), I see that the version is 6.0.22 (the product version field).

Shouldn't the version be 6.0.24 since that is the highest dotnet 6 SDK/runtime version I have?

When running dotnet --info, I can see also 6.0.22 runtimes present but I am not completely sure why the newer version is not chosen. I would expect the process to pick the newest minor version present. Is that not the case?

I am researching this topic because we are seeing a security tool reporting the same dll having version 6.0.2 inside an Azure resource making it vulnerable to CVE-2023-44487. The solution, per the tool, is to have the DLL have version 6.0.23 or higher. I am still checking more information about what the specific resource in question is so in the meantime I am asking this general question hoping to get some more info on how these dll versions get chosen.

Does System.Core.dll's version depend on the SDK version used to build the app or the version used by the app service/Azure function to run the app?

I would say the build process determines that, but I'd appreciate some feedback.


A set of technologies in the .NET Framework for building web applications and XML web services.
3,790 questions
Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
6,087 questions
0 comments No comments
{count} votes

Accepted answer
  1. Bruce ( 48,976 Reputation points

    all the runtime dll's have their own version independent of the sdk version. .an sdk version is a matched set of dll built against each other.

    dotnet --info

    pick a runtime folder, and you can check the version of each dll in that runtime.

1 additional answer

Sort by: Most helpful
  1. Lex Li (Microsoft) 4,031 Reputation points

    You should use MSBuild bin log to learn from where such files (in refs folder) come from, and then ignore them if just being used as referenced assemblies, Vulnerabilities are only valid if presented in runtime assemblies, and for that you need to follow the right approach to remedy according to the deployment method you choose, FDD or SCD.