- 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
X86 And X64 Platform Related issues
X86/X64 platform related issues are very common when executing tests using different test runners, and NCrunch is no exception to this. Because NCrunch is also integrated with the build process, there is an extra dimension of complexity that is worth understanding when trying to troubleshoot platform related issues within the NCrunch environment.
NCrunch Building To Wrong Platform
If you notice that the output assembly built by NCrunch (in one of its workspaces) is targeting the wrong CPU architecture, be aware that this problem is likely to be caused by differences in the way that NCrunch handles the $(Configuration) and $(Platform) build properties (see project build platform and configuration).
By default, NCrunch will always build to the CPU architecture that is defined within the project file. It is possible to change the CPU architecture via NCrunch configuration through the use of the use build platform setting.
Test Environment CPU Architecture
NCrunch will apply certain rules when deciding the CPU architecture that should be used within its testing environment:
- Firstly, NCrunch will consider the target platform of the test assembly as output from the build process. If the platform of this assembly is set to anything other than AnyCPU, NCrunch will use this platform in building the test environment and will consider nothing further.
- Where the test assembly is built to target AnyCPU, NCrunch will then inspect the use cpu architecture NCrunch configuration setting on the test project. If this setting is anything other than AutoDetect, NCrunch will use the platform specified and will consider nothing further.
- Finally, if the assembly was built to a target platform of AnyCPU and the use cpu architecture setting is AutoDetect, NCrunch will default to an X86 test environment.
Common Pitfalls And Recommendations
MSTest relies on a global .testsettings file to specify the target platform that should be used in a test environment. NCrunch does not consider the .testsettings file. Instead, adjust the use cpu architecture setting to set the target platform for your test environment.
There is a lack of standardisation between test runners in which processor architecture should be used in a test environment. Best practice is to always set up test projects with a target build platform identical to the platform that should be used inside the test environment. In this way, it should be very easy to understand which platform will be used for the test environment, as the output assembly won't support anything else.
By configuring your test projects with a target platform of AnyCPU, you are effectively stating that the tests within the project and all referenced code can function without problems in both X86 and X64 environments. If you have code within the test project or referenced by the test project that does not fit this description, then do not use AnyCPU.
