How does this differ from CDX-Gen -t dotnet

[fourofspades]

I have scanned our .net8 project with both, and if anything CDX-Gen was quicker and more comprehensive in it's results.

It's unclear when to use one over the other. Can someone explain?

Thanks.

[mtsfoni]

First of all: Both are CycloneDX ecosystem projects and produce spec-compliant SBOMs – it’s really about which trade-offs matter for your use case. As the maintainer of cyclonedx-dotnet I am likely biased (and I know better how to get good results in this tool than in CDX-Gen)

I just ran both tools against a test .NET project with 9 direct NuGet dependencies to compare them side by side:

Version resolution accuracy: This is where it gets interesting. When you point cyclonedx-dotnet correctly at the root project, it gives you exactly the resolved dependency graph – the versions that actually ship. With -ipr you get the full picture including project references as components, with correct per-project dependency edges reflecting NuGet’s resolution. cdxgen picks up the project structure automatically, which is nice, but in my test it produced some inaccurate dependency edges – attributing resolved versions from one project context to another, and duplicate entries with conflicting information.

Where cdxgen shines: It adds evidence fields (provenance tracking – how each component was discovered, confidence scores) that cyclonedx-dotnet doesn’t produce. It’s also polyglot, so if you have a mixed repo it’s one tool for everything. And it was genuinely quick.

For a pure .NET project, cyclonedx-dotnet gives you more accurate and complete results with less configuration. It understands NuGet resolution deeply, which makes sense – it’s purpose-built for the ecosystem. cdxgen is a solid general-purpose tool and the evidence metadata is genuinely useful for auditing, but for .NET specifically you’re getting better fidelity from the specialized tool.

---

I’m curious – when you say cdxgen was more comprehensive, could you share what specifically you saw? More components detected, or richer metadata per component? And did you pass any particular flags to either tool? For cyclonedx-dotnet specifically, did you point it at the .sln or .csproj, and did you use --recursive? I’m wondering if something in the cyclonedx-dotnet invocation caused it to miss packages in your case.

---

Bottom line: If you use C# a lot / you have many C# projects use cyclonedx-dotnet especially if correctness is an important factor.