- Overview
- Guides
- Concepts
- Considerations And Constraints
- Absolute File References
- Assembly Colocation Assumptions
- Concurrent Use Of Test Resources
- Cross Application Domain Testing
- Heavily Executed Code Under Test
- Implicit File Dependencies
- Multi Threaded Tests
- Netstandard Test Projects
- Project Atomicity
- Project Build Platform And Configuration
- Rdi Data Point Location
- Test Atomicity
- Unique Test Names
- Using NCrunch With Source Control
- Reference
- Global Configuration
- Overview
- Auto Adjust Clashing Marker Colours
- Build Log Verbosity
- Build Process Memory Limit
- Capabilities Of This Computer
- Coverage Marker Style
- Cpu Cores Assigned To NCrunch Or Ide
- Custom Environment Variables
- Disable Global Hotkey
- Engine Hosting Strategy
- Fast Lane Threads
- Fast Lane Threshold
- Grid Maximum Reconnection Attempts
- Grid Reconnection Delay
- Impact Detection Mode
- Listening Port
- Log To Output Window
- Logging Verbosity
- Marker Colours
- Max Failing Test Trace Log Size
- Max Number Of Processing Threads
- Max Passing Test Trace Log Size
- Max Test Runners To Pool
- NCrunch Tool Window Colors
- Node Id (Name)
- Password
- Performance Aggregation Type
- Performance Display Sensitivity
- Pipeline Optimisation Priority
- Rdi Storage Settings
- Sliding Build Delay
- Snapshot Storage Directory
- Solution Storage Data Limit
- Spinner Colours
- Terminate Test Runners On Complete
- Test Process Memory Limit
- Tests To Execute On This Machine
- Text Output Font
- Workspace Base Path
- Solution Configuration
- Overview
- Additional Files For Grid Processing
- Additional Files To Include
- Allow Parallel Test Execution
- Allow Tests In Parallel With Themselves
- Infer Project References Using Assembly
- Instrumentation Mode
- NCrunch Cache Storage Path
- Only Consider Tests Outofdate If Impacted
- Project Config File Storage Path
- Show Coverage For Tests
- Show Metrics For Tests
- Tests To Execute Automatically
- Project Configuration
- Overview
- Additional Files To Include
- Allow Dynamic Code Contract Checks
- Allow Static Code Contract Checks
- Analyse Line Execution Times
- Autodetect Nuget Build Dependencies
- Build Priority
- Build Process Cpu Architecture
- Build Sdk
- Collect Control Flow During Execution
- Consider Inconclusive Tests As Passing
- Copied Project Dependencies
- Copy Referenced Assemblies To Workspace
- Custom Build Properties
- Data Storage File Size
- Default Test Timeout
- Detect Stack Overflow
- Enable Rdi
- Files Excluded From Auto Build
- Framework Utilisation Types
- Ignore This Component Completely
- Implicit Project Dependencies
- Include Static References In Workspace
- Instrument Output Assembly
- Method Data Limit
- Ms Test Thread Apartment State
- Preload Assembly References
- Prevent Signing Of Assembly
- Proxy Process File Path
- Rdi Cache Size
- Required Capabilities
- Restrict Tostring Usage
- Run Pre Or Post Build Events
- String Length Limit
- Track File Dependencies
- Use Build Configuration
- Use Build Platform
- Use Cpu Architecture
- Runtime Framework
- Overview
- Atomic Attribute
- Category Attribute
- Collect Control Flow Attribute
- Distribute By Capabilities
- Duplicate By Dimensions
- Enable Rdi Attribute
- Environment Class
- Exclusively Uses Attribute
- Inclusively Uses Attribute
- Isolated Attribute
- Method Data Limit Attribute
- Requires Capability Attribute
- Restrict Tostring Attribute
- Serial Attribute
- String Length Limit Attribute
- Timeout Attribute
- Uses Threads Attribute
- Global Configuration
- Troubleshooting
- Tools
- Keyboard Shortcuts
- Manual Installation Instructions
Infer Project References Using Assembly Name
Solution-level NCrunch configuration setting Default Value: FalseID/Tag in config file: InferProjectReferencesUsingAssemblyNames
Purpose
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.
Recommendations
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.