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.

  • 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 '13 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 '13 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 '13 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 '13 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 '13 at 8:34
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.

  • 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 '13 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 '13 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 '13 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 '13 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.

  • 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 '13 at 7:39
  • I'm guessing it was done as an attempt to separate concerns. – CodeART Sep 17 '13 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 '13 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.

  • 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 '13 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 '13 at 7:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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