Tharga.Cache 1.0.0 ships FluentAssertions as a public NuGet dependency, so every consumer of the package inherits it as a compile and runtime dependency.
Evidence
tharga.cache.nuspec (1.0.0):
<group targetFramework="net10.0">
<dependency id="FluentAssertions" version="8.10.0" exclude="Build,Analyzers" />
<dependency id="Microsoft.Extensions.Hosting.Abstractions" version="10.0.9" exclude="Build,Analyzers" />
</group>
Only Build and Analyzers are excluded, so compile and runtime assets flow through to consumers.
The dependency appears to be unintentional — the shipped assembly does not reference FluentAssertions at all. Scanning lib/net10.0/Tharga.Cache.dll for assembly-reference strings finds Microsoft.Extensions.Hosting.Abstractions but no FluentAssertions.
Why this matters
Licensing. FluentAssertions 8.x is under the Xceed Community License — free for open-source and non-commercial use, but requiring a paid licence for commercial use. Flowing it to consumers as a transitive runtime dependency silently propagates that obligation to anyone who installs Tharga.Cache, directly or indirectly. This is the significant half of the problem: a caching library should not put a licence condition on its consumers.
Build breakage. Because the dependency is >= 8.10.0, any consumer pinning an older FluentAssertions in their test project gets a hard NU1605 package-downgrade error rather than a warning.
Encountered in a downstream app via:
HallenMedlem.Server
-> Quilt4Net.Toolkit.Health 1.0.0
-> Quilt4Net.Toolkit 1.0.0
-> Tharga.Cache 1.0.0
-> FluentAssertions (>= 8.10.0)
error NU1605: Detected package downgrade: FluentAssertions from 8.10.0 to 8.8.0.
The consumer had no way to know a caching package would constrain their assertion library version.
Suggested fix
If the reference lives in the library project for test-helper reasons, mark it non-flowing:
<PackageReference Include="FluentAssertions" Version="8.10.0" PrivateAssets="all" />
If it is not used by the library at all — which the assembly scan suggests — remove it from the library project entirely and keep it only in the test project.
Worth checking whether the same reference leaks from any sibling Tharga.* packages built from a shared Directory.Build.props, since that is a common source of this pattern.
Tharga.Cache1.0.0 ships FluentAssertions as a public NuGet dependency, so every consumer of the package inherits it as a compile and runtime dependency.Evidence
tharga.cache.nuspec(1.0.0):Only
BuildandAnalyzersare excluded, socompileandruntimeassets flow through to consumers.The dependency appears to be unintentional — the shipped assembly does not reference FluentAssertions at all. Scanning
lib/net10.0/Tharga.Cache.dllfor assembly-reference strings findsMicrosoft.Extensions.Hosting.Abstractionsbut noFluentAssertions.Why this matters
Licensing. FluentAssertions 8.x is under the Xceed Community License — free for open-source and non-commercial use, but requiring a paid licence for commercial use. Flowing it to consumers as a transitive runtime dependency silently propagates that obligation to anyone who installs
Tharga.Cache, directly or indirectly. This is the significant half of the problem: a caching library should not put a licence condition on its consumers.Build breakage. Because the dependency is
>= 8.10.0, any consumer pinning an older FluentAssertions in their test project gets a hardNU1605package-downgrade error rather than a warning.Encountered in a downstream app via:
The consumer had no way to know a caching package would constrain their assertion library version.
Suggested fix
If the reference lives in the library project for test-helper reasons, mark it non-flowing:
If it is not used by the library at all — which the assembly scan suggests — remove it from the library project entirely and keep it only in the test project.
Worth checking whether the same reference leaks from any sibling
Tharga.*packages built from a sharedDirectory.Build.props, since that is a common source of this pattern.