Add option to set search directories for dependencies of instrumented modules

[viktorgobbi]

Problem

When instrumenting assemblies that reference dependencies located in non-standard directories (e.g. satellite assemblies, shared native interop wrappers, or multi-project output layouts where DLLs are scattered across folders), Coverlet's Cecil-based assembly resolver only searches the directory that contains the module under instrumentation. This causes preflight resolution failures (UnresolvableDependencies) and prevents those modules from being instrumented, silently dropping them from coverage even though they are valid targets.
We have multiple projects that are extensions/addins for other products, many of the assemblies we reference are already loaded in the processes that loads our extension and therefore we avoid having these assemblies in the project output.

Proposed solution:

Add a new option, e.g. --coverlet-dependency-search-directory, that accepts one or more directory paths to be registered as additional search directories on the NetstandardAwareAssemblyResolver used during both preflight resolution checks and module instrumentation.

CLI (coverlet.MTP)

dotnet test -- --coverlet --coverlet-dependency-search-directory path\to\extra\dir1 --coverlet-dependency-search-directory C:\path\to\extra\dir2

Config file (coverlet.mtp.appsettings.json)

{
  "Coverlet": {
    "DependencySearchDirectories": "path\\to\\extra\\dir1,C:\\path\\to\\extra\\dir2"
  }
}

The directories are added to the resolver in both Instrumenter.Preflight() (so unresolvable-dependency skipping is accurate) and Instrumenter.Instrument() (so Cecil can fully read and rewrite the module).

We have some unit tests that cover the assembly loading behavior so copying the dependencies required for coverlet to instrument the assemblies is not possible as it changes the assembly loading behavior and therefore causes tests to fail.

I've implemented this for coverlet.mtp on my local environment (mainly with the help of copilot) and it seems to work fine, I get the full coverage now when I provide the missing dependencies coverlet needs to instrument all assemblies via the new parameter.

I'm happy to provide a pull request for this.

[Bertk]

Thank you for the proposal.

While an additional --coverlet-dependency-search-directory option seems feasible, a better approach for obtaining more complete coverage may be to use dotnet publish and run the tests from the publish output directory.

Could you please try this and let us know whether it resolves the issue?

[viktorgobbi]

@Bertk as I wrote in my original post, the problem is not the fact that I'm missing the dependency in the output directory, but that it cannot be in the output directory or otherwise the test will fail. I am aware that this is an unusual situation and probably an issue of our own making.

But I think the more important detail here is, that this only happens with the nightly build (10.0.2-preview.33.g61d8e1b154) and not with the currently released nuget package ( 10.0.1).
I've setup a small project to demonstrate it.

The difference is pretty drastic IMO. Without the --diagnostic setting enabled, it is not even visible why most of the coverage disappeared, in the example it's pretty clear but we have solutions with 10+ unit test projects which makes it hard to spot when something suddenly disappears without notice.

CoverletMissingDepRepro.zip

Extracting and running the repro.bat should show the difference.

[Bertk]

Thank you for the reproduction ZIP file. After modifying the source code, the nightly and release builds now produce identical results.

Important

coverlet.MTP automatically excludes the test assembly, as required by the MTP design. Therefore, SUT assemblies must not use matching names.

Changes made:

• Renamed projects and namespaces.
• Removed obsolete Properties/AssemblyInfo.cs files (Set assembly attributes in a project file)
• Removed UnrelatedClass.cs.
• Ran the tests with options: --coverlet --coverlet-exclude-assemblies-without-sources MissingAll --diagnostic --diagnostic-verbosity trace --diagnostic-file-prefix TestsNightly --results-directory ./TestResults

coverlet-issue-MissingDepRepro.zip

[viktorgobbi]

@Bertk thanks for the reply but I think we had a misunderstanding...

My example was explicitly for cases where a dependency of the assembly-under-test is missing from the output.
In your modified example, the project file is changed to include the assembly again and the class that was using it, is removed.
The section in the unit tests project files was there on purpose to suppress the DependencyLib.dll in the test project's output directory. I know that removing this "resolves" the issue but this was just to demonstrate the issue.

<ProjectReference Include="..\DependencyLib\DependencyLib.csproj">
  <Private>False</Private> <!-- Suppresses DependencyLib.dll in project output --> 
</ProjectReference>

The UnrelatedClass was there to show that this missing assembly was used but not required to run the tests (and is even marked with ExcludeFromCodeCover).

I meant to demonstrate that this (not having all assemblies referenced in the assembly-under-test in the output) used to work (and still works fine with coverlet 10.0.1) but does not work with the nightly build.

Regarding the matching names you pointed out: I was convinced, that naming the unit test projects the same as the project-under-test with the additional .Tests suffix was common practice in .NET/C#. Event this project is using exactly that nomenclature e.g. coverlet.core has a test project named coverlet.core.tests and the documentation in the default exclusions behavior section mentions

[...] Assemblies that do not follow these naming conventions will not be automatically excluded by the dynamic filter.

[Bertk]

@viktorgobbi My intention was to get identical code coverage results with both the released version and the nightly build.

The typical scenario for code coverage reports includes the dependencies of the SUT, and exclusions can be defined using the —coverlet-exclude option.

The nightly build simply ignores missing assemblies during the preflight check, whereas the released version may fail if a dependency is missing. This can be troubleshooted using the diagnostic logging information, but sometimes the missing dependency is itself a dependency of another dependency, which makes the root cause difficult to identify.

I’m not sure whether the reproduction sources are helpful, since they use an artificial setup that might not accurately represent the problem you’re encountering. Please provide an excerpt from a diagnostic log file which can be for analysis.

[viktorgobbi]

@Bertk I agree that the solution to reproduce this issue is an artificial setup, however we have a very similar situation in many projects, this was just meant to illustrate the problem I'm facing.

But what I actually wanted to point out is, that the nightly build completely ignores my assembly-under-test now when one of its dependencies is missing. The currently released version does not do that, it generates the coverage fine.
Therefore to me this felt more like a regression and not something deliberate. If this would be released as a minor version and I'd upgrade, I'd suddenly lose all coverage on those projects without seeing a single error or warning when the diagnostic log is not enabled.

In our case this happens when we use external APIs in our projects. The required assemblies are already installed with another product and we don't deliver them with our product. So we don't need to test them and everything related to them is excluded from coverage and not executed in the unit tests but they still need to be referenced. This is exactly what a wanted to show with the UnrelatedClass in my example that is used in the unit tests and is the only pace where the DependencyLib is used. If you run the unit tests without coverlet they run just fine without the DependencyLib.dll.
This was never a problem with other coverage tool and does not seem to be a problem with coverlet 10.0.1.

I think this was introduced with #1967 where the original issue was a locked file if I read the issue correctly, but after this pull request, instead of silently ignoring unresolvable dependencies of an assembly-under-test, the whole assembly-under-test is silently ignored when at least one of its dependencies is missing.
The change now forces all references to be present even if the CLR never loads some of them at runtime when the tests are executed as the are not required for the execution paths of the unit tests.

Maybe something like a database drive is a better example, you'd need to reference it as it is required for production code but it would not be unit tested, so you wouldn't need to have it in the output directory for unit tests.

I ran my example again with --coverlet-exclude-assemblies-without-sources MissingAll --diagnostic and a --coverlet-exclude for the test assembly itself for a clear output.

1. Is just starting the tests, run fine without the DependencyLib.dll in the output
2. Is the coverlet nightly build that shows 0% coverage and not a single covered assembly
3. Is the same thing as 2. just with the released nuget package of coverlet.mtp (10.0.1) and it shows 100% coverage and the assembly-under-tests.

As expected the diagnostic log for the nightly build contains a warning about the missing dependency and that the whole module is therefore skipped which is exactly my problem.

2026-08-25T12:48:32.0831881+00:00 Coverlet WARNING Skipping module 'C:\temp\CoverletMissingDepRepro\CoverletMissingDepRepro.TestsNightly\bin\Debug\net472\CoverletMissingDepRepro.dll': UnresolvableDependencies. Failed to resolve assembly reference 'DependencyLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null': Failed to resolve assembly: 'DependencyLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'

The diagnostic log for the released version contains no warnings.

[Bertk]

I reviewed the reproduction ZIP again and removed the following configuration:

<ProjectReference Include="..\DependencyLib\DependencyLib.csproj">
  <Private>False</Private>
</ProjectReference>

I also excluded it with:

--coverlet-exclude [DependencyLib]*

Coverlet’s instrumentation exclusion logic can now handle DependencyLib, which was previously not visible.
With these changes, Coverlet produced a valid coverage result rather than an empty report.

coverlet-issue-2014.zip