title: Good practice for working with multiple solutions in Visual C# Express
body: <p><strong>Background</strong>: My team is made up of 3 fairly inexperienced developers. We are developing in-house software for our company. Currently we have a number of smaller and separate solutions. Many of these are interdependent. Currently these depencies are made by referencing the output dll's in the respective release-folder. Updates are pushed around by manually rebuilding dependent solutions. </p>
  
  <p><strong>Example:</strong>
  Solution A uses features of solution B. The connection is made having Solution A referencing ...\Release\B.dll . Changes to B propagates by building solution B, then building solution A and so forth. </p>
  
  <p>This has worked okay before, but now we are moving from a manual (mind numbing) "version control system" (folder1, folder2, folder2New...) to using a proper one (git). </p>
  
  <p>It seems that versioning the .dll's is not recommended. This means that every time someone wants to build a new version of A, he also needs to build B (and maybe 5 other solutions) in order to have the latest version of B.</p>
  
  <p>I'm thinking that there must be a better way to do this.
  I've been looking at combining the relevant solutions into one master solution, but I can't figure out how to do this in Visual C# Express (which we are using).</p>
  
  <p><strong>So at long last the questions:</strong></p>
  
  <ol>
  <li><p>Is having a master solution that builds everything the way to go?
  -- it seems so from MSDN but I can't figure out how to do this in Visual C# Express 2008, which leeds me to </p></li>
  <li><p>Is this even possible in Visual C# Express? If not, what is a
  good way of managing the problem?</p></li>
  </ol>
  
  <p><strong>Edit</strong> Thanks to all for the great suggestions below. Here's a summary of what I ended up doing.</p>
  
  <p>In short the answers to the questions are: "Yes" and "Sort of, but mostly yes". I implemented as follows: In order to get an idea of the dependencies, I did as suggested below, and drew a map of the binary products, with an arrow pointing from the dll's or exe's name to all of its dependencies. </p>
  
  <p>For each <em>project</em>, I opened its corresponding <em>solution</em> (since at first there was <em>one</em> solution pr project). I then added the projectfile of each dependency in the tree structure revealed in the graph (by right-clicking the solution in solution explorer), so that also dependecies's dependencies and so forth were included. Then I removed the old references (pointing directly to the .dlls) and added references to the projects instead.</p>
  
  <p>The important result is:</p>
  
  <ul>
  <li>When a solution of a project is built, all it's dependencies are built with it, so that when deploying, you know that all the build products are automatically of the latest version. </li>
  </ul>