3

I need evidences and resources please, I have many projects, related to each other, I have permeation to get their code, I am working only on a small subset of them, and I have the latest version of all the binaries of the other projects, is it better to add only the projects those I work with and add the references as dll references, or add the other projects even if I don't need to change them or look at them.

Is it a personal preference? and why? what is the best practice?

Note: project count is increasing, they are now: 25 projects, and counting!

Please provide references and links, not a general answer.

Note: all of the projects are developed by our team, not an external open-source projects

Saw
  • 6,199
  • 11
  • 53
  • 104
  • sounds like you want us to research for you – JeremyWeir Mar 01 '13 at 18:03
  • No, I have searched and didn't found any clear answer, or even an answer. – Saw Mar 01 '13 at 18:04
  • So if you've exhausted the internet, that basically leaves opinions. – JeremyWeir Mar 01 '13 at 18:06
  • 1
    You may want to try rewording your question, since in its current form it is a bit too generic. Answers should have a correct answer. For example, Microsoft puts out recommendations for many topics, so asking what their recommendation is would provide a more concrete basis for an answer to be complete. [Here is a similar question to that vein](http://stackoverflow.com/questions/284856/is-there-any-best-practices-for-visual-studio-project-solution-structure) – Guvante Mar 01 '13 at 18:06
  • 1
    You are right @Guvante but StenPetrov 's answer is a good general answer for my question, and I think will be useful for others. – Saw Mar 01 '13 at 18:16

2 Answers2

6

It's NOT a personal preference.

Whenever possible you should reference the projects themselves rather than the DLLs they produce. Here's why:

  • building Debug and Release will produce consistent output
  • there won't be stale references
  • VS knows what to build when something changes, especially important when you have chained references A->B->C, changing A's dll won't cause C to be rebuilt if using DLLs

The only possible concern to have would be how many projects you're using. If too many then break up the solution in parts where each part is itself consistent and references all projects involved, so SolutionA has Project1, Project2, Project3 and SolutionB has Project3,Project4 and Project5 but building either will still produce a consistent build. Sill keep a solution around that has all the projects for release builds.

25 projects is still manageable. You can also have one solution with projects grouped under different solution folders so it's not one big list of 25 in VS's solution explorer but they still build at the same time.

Sten Petrov
  • 10,943
  • 1
  • 41
  • 61
  • Just to provide a different perspective: We have more than two hundred and fifty individual assemblies across all our products. Clearly that's a different scale, and we had to have a different solution. We use MSBuild to manage our builds, and we have custom tools which determine the project dependencies and produce the build file for MSBuild. But if you only have a few projects, you'll be better off with one solution, like Sten says. – Matthew Watson Mar 01 '13 at 18:19
  • @MatthewWatson at 250 projects you'd definitely need multiple solutions and likely custom builds, but I'd avoid that as much as *possible* as it carries its own headaches – Sten Petrov Mar 01 '13 at 19:13
1

Every project that you have in your solution is referenced as a DLL. So that is the same. The only difference is that if you don't have to change some code in any of the 25 projects often it will be very bad every time you do a rebuild.

The issue is as follows: When you build a solution, if the referenced project was not changed it will not be build. So that is the same as not having all the projects in the solution.

But if you do a clean and build, all the projects DLLs from the solution will be deleted and all projects will be built againg. This is going to take longer.

This are the only two things that I can come up with at this moment.

Cristian Chereches
  • 505
  • 2
  • 11