This configuration setting specifies a list of projects that a project depends on, but are not specified as references in the project file.
NCrunch normally identifies the references between projects by examining the ProjectReference elements inside the project build XML. This means that cross-project references not specified in this way are not considered by NCrunch and can only be identified through the use of this configuration setting.
When a project reference is specified using this setting, the NCrunch engine will consider the reference as part of its build dependency tree and will not build the referencing project until the referenced project has been built.
During test execution, it is possible to retrieve the file paths of implicitly referenced assemblies using the environment class.
You can use this configuration setting to work around issues caused by NCrunch's workspacing. If your solution contains code that dynamically loads referenced assemblies or builds custom application domains/processes from unreferenced projects, this setting allows you to inform the NCrunch engine of implicit dependencies and the environment class allows you to find these dependencies at runtime.
Because other test runners do not support the implicit reference data used by NCrunch, it is recommend only to make use of this configuration setting as a workaround that is specific to NCrunch's test environment. You can implement alternative logic for other test runners using NCrunch specific overrides.
If you have an x64 test library that needs to launch an x86 console application that is output from another project in the solution, there is no normal way to find the location of the x86 console .exe inside NCrunch's workspaces. When tests within the x64 environment are executing, they cannot locate the .exe because the NCrunch workspace containing it is stored in a undetermined location.
The normal solution to this problem would be to introduce a project reference from the x64 project to the x86 project (or a test project referencing both), then rely on the CLR's loading of referenced assemblies to find the location of the x86 .exe (for example, using typeof(ClassWithin32BitAssembly).Assembly.Location). Unfortunately, A reference cannot be created from the x64 project to the x86 project, because this would cause an InvalidProgramException to be thrown inside the test environment as soon as the CLR attempts to resolve the x86 assembly.
This configuration setting provides an alternative approach. When an implicit reference is created from the x64 project to the x86 project, it is possible to make a call to NCrunchEnvironment.GetImplicitlyReferencedAssemblyLocations() to find the location of the x86 .exe.