dynamically loaded assemblies

I'm testing an app that dynamically loads assemblies at run time, based on configuration. I noticed in comparing the list of assemblies in the coverage report to the list of assemblies that are built with the app, that there are quite a few that are not being profiled. In this case, a figure of 30% coverage would be misleading, because the 30% applies only to the assemblies that were actually loaded by the app.

Do you have any general advice for such a scenario, other than making sure that I run tests under configurations that will load all assemblies?

RE: dynamically loaded assemblies

When you say they are not being profiled, are they showing up in the coverage file?

Do you have the PDB files in the same folder as the dlls?

Joe Feser

RE: dynamically loaded assemblies

When I say not being profiled, I mean they do not show up in the coverage file. Yes, PDB files are in same folder as dlls.

The scenario is such that SessionA might load dll1, dll2, dll3 and SessionB might load dll3, dll4, dll5, dll6. But neither session loads dll7, so that dll7 is excluded from coverage analysis.

It's a plugin architecture, and the app only loads the assemblies which are needed. Roughly, each dll is a plugin.

RE: dynamically loaded assemblies

as long as the assemblies are .NET (IL) assemblies and they are being loaded with something like "Assembly.Load", then NCover should pick them up. To troubleshoot the problem, tell NCover to create a log file (//l ) and then search it for the names of the assemblies you expect. General information about why NCover failed to cover those assemblies should be nearby. If you post the relevant sections of the log to the forum, I can take a look and tell you what I think.

Regards, Stephen Ward