V5 Documentation

Infer Project References Using Assembly Name

Solution-level NCrunch configuration setting Default Value: False
ID/Tag in config file: InferProjectReferencesUsingAssemblyNames


This feature controls NCrunch's behaviour when resolving references between projects inside the solution.

When this setting is disabled (the default), NCrunch will rely on cross-project dependencies to be declared using the 'ProjectReference' build XML element. Cross project references that are not specified as true project references (for example, if they are using a 'Reference' element instead) will instead be considered assembly references. This will often result in NCrunch displaying warnings about 'lost project references' where assembly references appear suspicious.

When this setting is enabled, NCrunch will continue to use the 'ProjectReference' build XML element to resolve cross-project dependencies, but it will also try to infer these dependencies using the assembly names of projects built within the solution. If a project declares a 'Reference' to an assembly with a name that matches the output assembly name of another project in the solution, NCrunch will consider this reference to actually be a project reference rather than an assembly reference.


This setting is useful when working in solutions that do not follow the standard approach of using project references to declare dependencies inside the solution.

When projects declare their dependencies using assembly references, NCrunch is normally unable to identify the true nature of these dependencies. This results in a loss of code coverage in referenced projects and can create obscure problems related to build order and code versioning. By infering project references based on assembly name, NCrunch is able to compensate for non-standard solution structures and can operate normally.

This setting should be used with extreme care. Project references that are declared as assembly references are effectively an anti-pattern inside a solution's build structure, as without proper care they can introduce build sequencing problems and other dependency issues that may not always be obvious while working with the solution day-to-day. These problems have a tendency to appear when performing release builds or fresh VCS checkouts, as they lean heavily on implied behaviour inside MSBuild that can mask them until the worst possible time. Enabling this configuration setting effectively asks NCrunch to turn a blind eye to these sorts of problems, removing a potential red flag that could save future time and trouble. You should only enable this setting if you have a solid understanding of your solution's build process and have concluded that there is no better way to structure your solution.

Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download