- 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
Implicit File Dependencies
Description
When preparing to build a project, NCrunch will copy all known files within the project to a workspace to create a cloned version of the project for background processing.
NCrunch automatically tracks all files that have been included in a .proj file, considering these files to be a part of the project and needing to exist in any isolated workspace built for the project.
Possible Problems
Because NCrunch can only copy files into the workspace that it is aware of, there is a risk that implicitly or ambiguously referenced files may not be copied into the NCrunch workspace. This can create issues when NCrunch builds projects and runs tests, including FileNotFound exceptions or other more obscure problems.
Files missing from NCrunch workspaces account for the vast majority of reported problems when using NCrunch. There are many ways in which projects and tests can reference files on the file system, and not all of these ways can be reliably monitored by NCrunch.
An easy way to confirm whether you have important files missing from a project's workspace is to inspect the contents of the workspace using Windows Explorer, and compare it with the project the workspace was derived from. You can easily open an explorer window over a workspace by right-clicking a project or test in the NCrunch Tests Window, then choosing Advanced->Browse to workspace.
Solutions
Include Referenced Files In The Project
As a matter of convention, it is good practice to ensure all files that are relevant to a project are included in the project's .proj file.
This can also be done for files that exist in an upwards relative path from the .proj file itself - although the only way to specify this is to edit the .proj file directly. For example:
<ItemGroup> <None Include="..\Images\ImageFileOutsideProject.png" /> </ItemGroup>
The type of included file (i.e. 'None', 'Content', 'Compile') is of little functional relevance to NCrunch, so when including files in the project, a good approach is often to use the 'None' tag.
Use The Additional Files To Include Configuration Setting
The Additional files to include configuration setting can be used to include a specific file, directory, or range of files into the NCrunch workspace.
This option is a useful alternative to including references to the files directly in the .proj file, and is a far more effective way to specify whole directories of files that need to be included in the workspace.
A situation where this would work particularly well would be where a project is dependent upon a series of build tools or resources that exist upwards from its own directory (i.e. '..\BuildTools\*.*').
The Additional files to include configuration setting can be applied both at project level and solution level.