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.
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
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.
Thanks!
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.
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, https://halfblood.pro/the-rough-history-of-referenced-assemblies-7d752d92c18c 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.