- 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
Build Sdk
Project-level NCrunch configuration setting Introduced NCrunch v4.19 Default Value: (Depends on IDE)ID/Tag in config file: BuildSdk
Purpose
This setting specifies the version of MSBuild that should be used by NCrunch to build the associated project.
By changing this setting, it is possible to force NCrunch to use a version of MSBuild that is packaged with newer SDKs of .NET, particularly .NET 6 and above. Newer versions of the .NET SDK ship with their own versions of MSBuild and are installed separately to Visual Studio. This makes it possible to operate the NCrunch Grid Node or Console Tool on a machine that does not have Visual Studio installed.
When left as the default value, NCrunch will use the version of MSBuild that is best suited to the IDE currently being used. For example, when running VS2022, NCrunch will use the version of MSBuild that is packaged with VS2022. Under VS2010, NCrunch will use the version of MSBuild that is preinstalled on every Windows machine (as part of .NET Framework v4).
It is not possible to use this setting to force NCrunch to use a version of MSBuild packaged with Visual Studio if the version of VS is not the same as the one currently hosting NCrunch. For example, it is not possible to make NCrunch under VS2010 use the version of MSBuild installed in VS2022. This is because each installed version of NCrunch only ships with the binaries required to integrate with a single instance of VS.
If the specified version of MSBuild is unavailable, NCrunch will fall upward to a newer version (if found). Otherwise, it will fall downward to an older version. This can result in the build successfully completing, but a warning will be shown by NCrunch.
Recommendations
Unless you are working with a grid node or console runner machine without Visual Studio installed, this setting is generally best set to its default value. Running NCrunch with a different version of MSBuild to the one being hosted by Visual Studio can result in NCrunch's build behaviour being vastly different to the IDE, which can sometimes cause problems that are difficult to diagnose.
Changing this setting to use one of the newer non-VS dependent versions of MSBuild is useful if you want to operate a grid node without needing to install VS. Note that changing this setting will alter the build behaviour on both your local machine and the grid node, as the setting is passed over the network when the NCrunch client requests a node to build a project on its behalf.
Newer versions of MSBuild packaged in the .NET SDK are themselves running on newer versions of .NET, with the platform itself effectively being newer versions of .NET Core. Older build tasks that have not been maintained by Microsoft will likely fail to run under this platform. It should be expected that you will not be able to use these versions of MSBuild when working with old solutions that depend on deprecated toolsets.
