I prefer expressing the difference between project a solution owns and projects it does not own (dependencies) with the help of Visual Studio’s solution folders. It’s a trick I didn’t come up with myself, I’ve deftly stolen it from a former colleague.
There are four categories:
- The main project (in most cases a library or application)
- Other projects the solution owns, that the main project depends on.
- Test projects
- Dependencies: projects the solution does not own
For a little dummy project like this it seems like a lot of overhead, but I’ve experienced that the list of dependencies can become quite large and the number of test projects grows with the number of projects under 1. and 2. What I like most about this approach, is that if you consistently apply this across your solutions, you always know what to expect when opening a solution; at a glance you’ll see what it’s all about. All in all I find it worthwhile to apply this grouping.