Which visual studio solution type is right for me?

Question

I currently have a program that i wrote that is divided up into 3 separate solutions.

1. Front end (all display related stuff)
2. Parsers (multiple (39) projects that each create a dll to parse specific data)
3. Globals (multiple (5) projects that each create a dll that is used by projects in the parsers solution, and by the front end).

Requirements -

• Both the Front end and Parsers require the globals dlls to exist at compile time, and used at run time.
• The Parsers dlls are loaded at run time using assembly.LoadReference.
• Development is: C:\projects\myProg
• deployed location is: C:\myProg

My problem is that I have been going back and forth with issues dealing with project dependencies, where to point to for my globals dlls. Do I point to the deployed location or the developement location, and if so, release or debug?

So I started looking up the different solution types, and I'm wondering if I should set up a partitioned solution, or a multi-solution for my particular situation.

Answer 1

Add all the projects to a single solution.

Change any references between projects into "project references" rather than direct references to dll files. This will fix a lot of dependency issues.

If you have any "library" files that are not changed often, then you can optionally move them into a separate solution. The output of this should be "prebuilt" release dlls that you can then reference from a standard location in your main solution (the best way to do this is to add a post build step that copies the output to your development "library binaries" folder. That way, the build process is not changed, you simply add an extra step to get the files where you need them, and you remain in full control of the build process). This works well, but is a pain if you need to change these prebuilt dlls often, so it's best only used for fairly static parts of your codebase.

Finally, consider merging many of your projects into a single project/assembly. The killer on build times is not the amount of code, it's the number of assemblies - on my PC every project adds a pretty constant 3 seconds to the build time, so by merging small projects I've saved quite a bit of build time.