Multiple projects in a solution

Well, you could create one solution for a game your working on and then create different projects inside of that solution for things like the editor, the actual game, the engine etc.
From my experience, compilation and linking is pretty much the same as having different solutions for each project.

Having multiple projects in a solution allows you to resolve a number of otherwise frustrating issues for bigger projects


+ You can manage interdependancies between projects easily.

For example, if a project needs to be unit-tested, it is convenient to split the code into three parts, a library which contains all of the code to be tested, a unit test application and the driver application. Visual studio will force recompilations of both/either application if the library changes - something which you would otherwise have to do manually.

Additionally visual studio also uses dependancy information to implicitly add linking information. ie/ if an app depends on a library, that app is linked to that library


+ Reduces developer workload

Personally I find that unless the code I'm working on is segregated into reasonable sized 'chunks' (10-15 methods per class, 10-20 classes per namespace), the amount of mental effort required to remember where everything is starts to increase greatly. Being able to add an extra tier of 'chunking' through using projects embedded in a solution is one way that I do this.


- Costs

Recent studies have shown that visual studio project dependancy tracking is not as fast as what it could be - and in some cases not as accurate. Personally, I haven't had a problem with this.


I suggest that if you find yourself managing large volumes of code in the IDE, it's going to be pretty obvious which direction you need to move in.