2
\$\begingroup\$

I was wondering what would be the best way to go about organizing the projects for the XNA project I have been working on. It is a simple game that uses a client/server architecture.

Currently everything is in one solution that I open in Visual Studio. This solution consists of multiple projects. The client project, server project, content project, the game API project, and the networking library. It works this way, but it all feels cluttered it doesn't seem right from an architectural stand-point to have both the client and the server in the same solution.

Does it make sense to keep everything in one giant solution or should I have a separate solution for the client application and a separate solution for the server application. If I go about separating them how could I continue to use a shared API project between both solutions?

\$\endgroup\$
5
  • 1
    \$\begingroup\$ No worries, its a clear question. What bothers you about 1 solution? Thats the setup that I saw being used most of the time, in VS C++ though, but that shouldnt matter. Its very convenient, especially when debugging across the projects. So what bothers you about it? \$\endgroup\$ Commented Jan 27, 2013 at 0:48
  • \$\begingroup\$ Nothing really bothers me but I wasn't sure if it was the "correct/best" way to go. I am just trying to follow best practices. But it sometimes gets annoying when debugging the shared projects, because a breakpoint will be hit from the client and server, sometimes when I only want to debug from one side. \$\endgroup\$
    – aalcutt
    Commented Jan 27, 2013 at 0:51
  • 1
    \$\begingroup\$ I see, my advice, keep it that way and delete unused breakpoints once in a while :) \$\endgroup\$ Commented Jan 27, 2013 at 0:59
  • \$\begingroup\$ If your game will get really big, it might be faster to split up into 2 solutions since VS will build all projects in a solution even if you want to run just 1. \$\endgroup\$
    – Thomas
    Commented Jan 27, 2013 at 15:23
  • 1
    \$\begingroup\$ @Thomas That's only if you choose "Build All". If you build (or run) a specific project, VS is clever enough to skip anything that the project does not depend on. \$\endgroup\$ Commented Feb 1, 2013 at 11:11

1 Answer 1

3
\$\begingroup\$

In my experience it is highly preferred to work with all your projects in a single solution. There is one highly important reason for this: IntelliSense and the refactoring tools in Visual Studio.

Architecturally, your client and server almost certainly should rely on shared code that exists in one or more shared projects. And if you use any of the refactoring tools (especially: Rename, and Find All References) within one of those shared projects, you want that tool to take into consideration code in both the Client and Server projects that depends on it.


If you wish to work on the Client and the Server in two separate instances of Visual Studio - that is still possible. You can simply open the one solution twice. Visual Studio is still reasonably well behaved in this scenario.

Alternately, if you want to have only one instance of Visual Studio open - but still debug both the client and the server at the same time - you can run one or both projects without the debugger. If you have the full version of Visual Studio (not Express) you can attach and detach the debugger to either process at any time.

(An more creative alternative would be to organise your project such that a single process can act as both client and server at the same time.)


Of course - it's fairly easy to add and remove projects to solutions. So feel free to experiment and choose what works best for you.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ You can start debugging both projects at once. In solution > properties, you can select multiple startup projects. \$\endgroup\$
    – Kikaimaru
    Commented Feb 1, 2013 at 11:15
  • \$\begingroup\$ @Kikaimaru Completely forgot about that one - that option is quite far off the beaten track. Thanks for mentioning it :) \$\endgroup\$ Commented Feb 3, 2013 at 12:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .