- 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
NCrunch-Specific Overrides
Often when troubleshooting problems with NCrunch, it can be useful to introduce behavioural differences in your code or build process that are applicable only to NCrunch.
For example, you may have a custom build step performing an action that NCrunch shouldn't take, or a particular piece of test code that needs to be compiled slightly differently under NCrunch.
There are several ways of introducing conditional behaviour under NCrunch.
Conditional Build Behaviour
When executing any kind of build, NCrunch will always inject a special property that can be used to identify it during the build. The property is $(NCrunch) with a value of 1.
This property can be applied to standard build conditions within project files and build imports, for example:
<OutputPath Condition="'$(NCrunch)' == '1'">bin\</OutputPath> <OutputPath Condition="'$(NCrunch)' != '1'">bin\Debug\</OutputPath>
The above conditional OutputPath properties will introduce different build behaviour for NCrunch. All NCrunch builds will place build outputs directly into the bin directory, while normal builds will output to bin\Debug.
Because MSBuild conditions can be applied just about anywhere inside the build process, this is a very powerful way to introduce any kind of alternative build behaviour for NCrunch.
A possible alternative is to inject your own properties into MSBuild using NCrunch configuration.
Conditional Compilation
In C#, NCrunch builds declare a specialised compiler constant that makes conditional compilation very simple. The declared constant is NCRUNCH. Consider the following example:
#if NCRUNCH Console.WriteLine("Running under NCrunch"); #else Console.WriteLine("Running under something else"); #endif
When building and executing the above code, the text written to the console will be different between NCrunch and any other test runner.
Conditional Runtime Behaviour
Although conditional compilation is usually a cleaner approach to conditional runtime behaviour, it isn't available for every .NET language and may not be appealing in every situation.
NCrunch always sets an environment variable in its execution environment, which can be queried to identify when NCrunch is resident. This environment variable is under the name NCrunch and is always set to 1. For example:
if (Environment.GetEnvironmentVariable("NCrunch") == "1") { Console.WriteLine("Running under NCrunch"); } else { Console.WriteLine("Running under something else"); }
An alternative approach is to rely on the NCrunchEnvironment Class, which has a method that tests this environment variable itself:
if (NCrunch.Framework.NCrunchEnvironment.NCrunchIsResident()) { Console.WriteLine("Running under NCrunch"); } else { Console.WriteLine("Running under something else"); }