3

I've started working at this company, and the software is managed in a Visual Studio solution that includes hundreds of projects (C++ and C#). After poking around the solution for couple of weeks, I started wondering why there are so many projects. Not only does it slows down VS considerably, but a rebuild can take up to an hour.

Since a visual studio project corresponds to a physical deployment unit (be it a .NET dll, a C++ lib or an exe), there are reasons why you'd want code partitioned across projects. Some of those reasons can be found in this article.

In my particular case, none of the reasons in that article stood. There are roughly 5 processes running across tiers, maybe a few dynamically loaded assemblies used for a plug-in model, and some infrastructure which is rarely changed.

I don't see any need for more than ~50 VS projects for this solution, and I believe that merging them will increase productivity and will allow for a shorter feedback loop.

When I tried to suggest this to the software manager, his response was that they are trying to have as many dlls as possible so that when they plan to ship a new feature, QA can test just the behavior of the modified dlls without having to worry that something else was effected. He said that since a dll was not changed, it will behave the same. For this to work they aim for high granularity of deployment units.

Does this make sense to anyone? I don't see the difference in the effect on behavior between editing a single line in a project that has a single huge dll, and editing the same line in a project that includes hundreds of dlls.

EDIT

I'm looking for an answer on using assemblies/project as means for separating logical concerns and its effect on the testing effort. I would even go as far as saying that many assemblies that could give you more testing scenarios because of versioning incompatibilities.

So my distilled question is: When will you partition your code across projects/assemblies instead of namespaces in the same assembly, given that there are no runtime constraints, and why?

EDIT 2

I guess I'm looking for something like this article. However, I'm reluctant to post this as an answer and accept before I see if there are different opinions in the community.

Improve this question
11
  • 1
    One thing that I've found useful in situations like that (a sprawling solution and political resistance to consolidation) is to create your own solutions that include relevant subsets of the projects. This wipes out your long build/re-build times and makes the feedback loop much faster, especially if you are running some kind of continuous testing tool. You only have to run the big solution's build before checkins.
    – Erik Dietrich
    Sep 17, 2013 at 6:31
  • 1
    @ErikDietrich That's exactly what I've started doing since that talk. What I'm trying to figure out from this question here, is if there is any justification for that manager's approach.
    – moranlf
    Sep 17, 2013 at 6:39
  • What do you think "DLL Hell" means? Strikes me that avoiding DLL Hell (mismatched versions used by different applications) is one of very few advantages of having all your projects in a single solution.
    – pdr
    Sep 17, 2013 at 8:25
  • @pdr My problem is not with the large number of project in a single solution vs many solutions. It's about having many projects vs having less projects - in the same solution. see my edit
    – moranlf
    Sep 17, 2013 at 8:28
  • Then you're misusing the term. Having a lot of assemblies is not DLL hell. The problem you have here is that neither argument is particularly strong, like the spaces vs tabs argument, so all you're going to get is opinion. What you really should be asking is how you speed your build up. (Have you checked that you're not rebuilding, rather than building, and that you're not verbose logging unnecessarily?)
    – pdr
    Sep 17, 2013 at 8:34

3 Answers 3

Reset to default
3

QA as a whole is about assessing the risk that the product is suitable for the users to use. In reality, QA is not a 100% guarantee in part because it is usually impossible to test every possible action (including all non valid actions) in every possible environment.

Since you have limited QA resource, you have to make decisions about where to focus that resource to increase the likelihood that you detect critical bugs that have been missed by the developers.

The QA's comment about DLL's not changing means they can focus their testing effort better is correct. Although, it's correctness is decreased if the library is not version stamped by the autobuild system (how do you prove its the same DLL?) and its getting close to wrong if its a new DLL compiled from the same source code (did compiler options / toolset change - producing a different library?)... and if there is no mechanism that the QA actually do to audit that the source code between the two DLL's have not changed then its definitely wrong as QA cannot say with any confidence that a change has not slipped in.

I've worked on several teams that have large numbers of projects in the same solution file. It worked better for some than others. Things deteriorate when the number of projects files increase to such a point that Visual Studio starts becoming unstable. However, on a well designed architecture, that designs the DLL's inter-dependencies to a minimum and has a strong release and version management process it can be made to work well.

Improve this answer
4
  • I'm sorry, but I still don't get it. Lets assume for now that all dlls are signed and versioned such that QA knows exactly what changed (BTW, we also have source control for that). Wouldn't it be more safe to focus QA's effort on the change according to changes in source rather then the DLL? I return to the example in my question: given that QA knows that a single line was changed in a particular component (component here being a logically seperated entity), how will their testing focus change if the line is pacakged in a large dll or smaller dll?
    – moranlf
    Sep 17, 2013 at 8:17
  • 2
    QA is about managing risk. You have a limited time resource to provide your best effort at finding bugs. If you recompile the same source code and claim its the same DLL you are introducing risk that a code change occurred, that the compiler was updated on the build machine, that the source control had a glitch and left part of the previous build's source code there, that a DLL that this code depended on changed... All these are risks that need to be managed and assessed as part of the risk assessment.
    – Michael Shaw
    Sep 17, 2013 at 8:29
  • 1
    Your comment is on the spot. It makes me think why our scheduled build process always does a rebuild and automatically stamps all dlls with the current revision number...
    – moranlf
    Sep 17, 2013 at 8:37
  • I upvoted and accepted since I see that QA risk assessment is the reason for the manager's partitioning strategy. I still highly disagree that this assessment should be based on physical unit, but rather on logical, but that discussion probably doesn't belong here, on a Q&A site. Thanks.
    – moranlf
    Sep 17, 2013 at 11:12
1

I think having too many projects in a single solution is a bad thing. I have previously worked on the system that comprised of over 15 business domains. If I was to put them all into one solution, than I would end up with hundreds of projects. I suggest that you try and break these projects down into logical solutions (domains). In other words, work on separation of concerns.

In regards to build time - this can normally be improved. We had a system that took over an hour to build and after a year of work the time went down to under 10 minutes, which is a massive cost saving.

Improve this answer
3
  • I agree regarding a partitioning a large solution into smaller ones. But I'm looking for an answer with reasons to having a large number of projects in the first place, when their only function is a container around logical components. I guess this comes down to why having different projects instead of a single project with many namespaces, when there isn't deployment-related justification (like tier seperation, plug-ins etc.)
    – moranlf
    Sep 17, 2013 at 7:39
  • I'm guessing it was done as an attempt to separate concerns.
    – CodeART
    Sep 17, 2013 at 8:04
  • Right, but why are those concerns better separated when packaged in a different dll rather then a different namespace?
    – moranlf
    Sep 17, 2013 at 8:11
0

Yes, it does make a sense. The problem is it is still highly theoretical. I would question him if what he says, is really done in practice. Does QA really test individual DLLs or do they only test bigger parts of the project. Do they also test DLLs that have changed DLL as dependency? If no, how are they able to ensure it is also correctly working? There is also problem of actually tracking changes for each DLL. Because the more DLLs there are, the harder it is to track what DLLs were changed for specific feature/bugfix. Last thing that comes to mind is separation of concerns. If the structure of project is correct, then many changes would require change of only few DLLs. Preferably only one. This is rarely a case and more often than not, projects are in such a state that change propagates through many DLLs. In the end it is matter of compromise : Is the advantage of separate testing (with all that goes with it) higher than having really long build times and dealing with DLL hell?

I would definitely ask him, if what he says is just wishful thinking or real practice, that is actually advantageous.

Improve this answer
2
  • I'm really interested in this "highly theoretical" sense. I have yet to find any proven justification for using VS projects for logical partitioning (except for the ones mentioned in the article). Isn't that what namespaces are for?
    – moranlf
    Sep 17, 2013 at 6:47
  • @moranlf VS projects are best used as modules/packages. In which case, things like software package metrics and dependencies between packages. I'm just saying that while what your manager says is possible, it takes much more effort, than what person might think, to actually do right.
    – Euphoric
    Sep 17, 2013 at 7:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.