Thanks for sharing this. Having had a good think about this, I'm not sure if I can recommend an approach that would allow you to use NCrunch on this solution without having most of your project tree loaded into memory. NCrunch is able to load and work with projects that exist outside the current solution, though this still would require the use of project references and I think it would still place you in the situation that you are trying to avoid (i.e. having your entire project tree sitting in memory). In theory it's possible to set this up by introducing <ProjectReference> tags side-by-side with your <AssemblyReference> tags in the .proj files, and making these conditional on NCrunch vs Visual Studio builds - though this would be a nightmare to set up and maintain.
I have some long term plans to introduce features that may make your situation much easier, but I'm still working out the details of this and any reliable implementation is still many months away.
In a more general sense, when I think to projects I've worked on of a similar size, generally we would split the entire project tree up into smaller solutions that were well published within the team. While working between the solutions, we would often have multiple instances of the VS IDE open. It wasn't ideal, so we would often try to split projects between the solutions based on natural lines of architectural separation within the product to make the dependencies easier to control. Often when products reach the size you've described, they tend to be split up between multiple development teams anyway, which I think is how many people deal with this problem. I find your approach very interesting as it suggests there may be other ways to manage this.
Cheers,
Remco
