Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Incorrect dependency version // min-Version vs. runtime-Version

See original GitHub issue

I am having troubles with incorrectly resolved nuget package versions for transitive dependencies. Only the min-version of the dependency is used, not the “real” runtime version used.

Issue: min-version specified in nuget vs. runtime version used


<PackageReference Include="Azure.Storage.Blobs" Version="12.9.1" />

The component lists the dependencies (


cyclonedx-dotnet uses project.assest.json to collect all nuget dependencies. In the file the following entry can be found:

"Azure.Storage.Blobs/12.9.1": {
  "type": "package",
  "dependencies": {
    "Azure.Storage.Common": "12.8.0",
    "System.Text.Json": "4.6.0"
  "compile": {
    "lib/netstandard2.0/Azure.Storage.Blobs.dll": {}
  "runtime": {
    "lib/netstandard2.0/Azure.Storage.Blobs.dll": {}

But in fact the transitive dependency System.Text.Json is never used in the specific version, but the “real” version of the specific runtime is used. In my case 5.0.2 as show in the screenshot of the specific assembly:


My issue is, that the min version dependency System.Text.Json 4.6.0 is used in the bom.xml of cyclonedx-dotnet, which leads to a security vulnerability message in my CI pipeline, but in fact the version is never used, because the runtime version 5.0.2 is active.

<component type="library">
      <description>Provides high-performance and low-allocating types that serialize objects to JavaScript Object Notation (JSON) text and deserialize JSON text to objects, with UTF-8 support built-in. Also provides types to read and write JSON text encoded as UTF-8, and to create an in-memory document object model (DOM), that is read-only, for random access of the JSON elements within a structured view of the data.

Commonly Used Types:
When using NuGet 3.x this package requires at least version 3.4.</description>
        <hash alg="SHA-512">14882E14C01813FCB211A49C27516268F38DC356203895F0A415DFA1AECC02098DB9FD777C19D42B444BCA36AC0F096A4322DF1225F818ABEAB8D121D49C7750</hash>
      <copyright>© Microsoft Corporation. All rights reserved.</copyright>
        <reference type="website">

Question is how to deal with this issue, problem is that the information created by cyclonedx-dotnet is not 100% useful for the transitive dependencies because it lists “wrong” versions which result in false-positive alerts when versions are processed (security checks, …)

Issue Analytics

  • State:open
  • Created 2 years ago
  • Comments:8 (4 by maintainers)

github_iconTop GitHub Comments

bihecommented, Jul 7, 2021

yep - it is:

<Project Sdk="Microsoft.NET.Sdk.Web">



    <PackageReference Include="Azure.Storage.Queues" Version="12.7.0" />
    <PackageReference Include="Azure.Storage.Blobs" Version="12.9.1" />
    <PackageReference Include="Microsoft.Extensions.Hosting" Version="5.0.0" />
    <PackageReference Include="Serilog.AspNetCore" Version="4.1.0" />
    <PackageReference Include="Serilog.Sinks.Async" Version="1.5.0" />
    <PackageReference Include="Serilog.Settings.Configuration" Version="3.1.0" />
    <PackageReference Include="Serilog.Sinks.Console" Version="3.1.1" />
    <PackageReference Include="Serilog.Sinks.File" Version="5.0.0" />
    <PackageReference Include="Serilog.Enrichers.Thread" Version="3.1.0" />
    <PackageReference Include="Serilog.Enrichers.Environment" Version="2.1.3" />
    <PackageReference Include="Shuttle.Core.Cron" Version="10.1.0" />
    <PackageReference Include="Swashbuckle.AspNetCore" Version="6.1.4" />
    <PackageReference Include="Microsoft.AspNetCore.Hosting.WindowsServices" Version="5.0.7" />


Matiszakcommented, Feb 22, 2022

@coderpatros Hey, did you get any feedback ? As far as I’m understanding the nuget resolving mechanics (although still many things suprise me) the exact version of a system library (which is included in framework sdk) can be only determined at runtime because it depends on which runtime version (with what patches) you have installed locally.

But I’m interested if you have any more insight into it ? Could you maybe put the reference to docs regarding “All the documentation reads that project.assets.json, and especially packages.lock.json, should be a reliable source of truth for resolved dependencies.” ?

Read more comments on GitHub >

github_iconTop Results From Across the Web

Maven: Incorrect (and flaky) transitive dependency version
Dependency mediation - this determines what version of a dependency will be used when multiple versions of an artifact are encountered.
Read more >
Nuget package installer does not install dependencies (.net ...
I have a test project, wherin I'm using PeanutButter.TempDb.MySql (I'm also the owner/maintainer of the PeanutButter.* packages). This package depends on:.
Read more >
<uses-sdk> | Android Developers
Lets you express an application's compatibility with one or more versions of the Android platform, by means of an API level integer.
Read more >
Question - How to resolve Dependency Version Issues
I have c# code that is being run in a script component in SSIS. The code makes a connection to SharePoint Online. I...
Read more >
Specify a list of PEP 508 compliant dependencies that must be satisfied in the Python environment hosting tox when running the tox command....
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found