In VS2010, it isn't technically possible for NCrunch to start loading the projects until the IDE has completed it's loading of the solution, as VS won't send out project notifications until the solution is in place.

Most likely, the loss of responsiveness is being caused by heavy I/O activity. NCrunch won't monopolise the foreground thread or 'steal' background threads away from the IDE, and provided you've split the CPU resources appropriately between NCrunch and VS, it shouldn't slow any VS operations that are happening in memory. However, the builds kicked off by NCrunch cause large amounts of I/O, which can cause problems for VS activities (or activities of other plugins) that attempt to make blocking calls to the overloaded file system using the foreground VS thread.

There are several things you can do that may help this situation:

- If you are using a 3rd party code analysis tool of some kind (such as Resharper's solution-wide analysis), try disabling it to see if this makes a difference. Most other plugins will begin their analysis of your solution at roughly the same time as NCrunch, as they respond to the same notifications.
- If the on-disk size of your solution isn't too big, consider setting up a RAM disk and pointing your NCrunch 'Workspace base path' at this RAM disk. This will reduce the load on your HDD and will also give you a huge improvement in performance.
- Try reducing the value assigned to the 'Max number of processing threads' NCrunch global configuration setting. This will reduce the number of builds NCrunch can perform concurrency and will thus reduce I/O activity shortly after load.

I hope this helps!


Cheers,

Remco