Hi, thanks for posting!
The main vision of NCrunch has always been to try and get out of the way of the IDE and the normal build system. This is done for a number of reasons:
Interference with other user/IDE processes - Having a continuous test runner constantly locking files and manipulating the contents of build output directories while you are running your application or performing other development tasks can be extremely obstructive and tends to create a habit where you need to disable the continuous test runner whenever you're not actively watching it work. This reduces the value of the passive feedback NCrunch provides (i.e. you need to go looking for it, not just have it there in front of you).
Manipulation of build/test environment - NCrunch assumes full control over the build and test environment, performing activities such as instrumentation (which will actually change the binary form and behaviour of output assemblies). This means that the output from the NCrunch build process can be physically different from the normal Visual Studio build process, causing confusion in certain scenarios.
Difficulty of a clean implementation - There are certain operations that happen when code is saved in the IDE (such as code completion in VB.NET). Saving to disk on every key stroke can create certain usability issues that may be problematic (or impossible) to completely solve.
Less control of the build environment - Much of NCrunch's build performance comes from its ability to separate and isolate individual projects so that they may be built independently. This often leads to the duplication of projects inside NCrunch's workspace (for example, one project may be still running tests when NCrunch needs to rebuild it). Building projects inside the original solution path would force NCrunch to perform many of these operations synchronously, thus reducing the speed and efficiency of the engine.
There are in-betweens here. For example, it may be possible to implement a feature when tests are run on every save (instead of every keystroke), which would encourage you to save your code to disk regularly. Though long term, I have no plans to introduce closer integration between NCrunch's workspace and the original solution path.
Thanks!
Remco
