5

We have various projects in source control for web and desktop applications. Invariably, many of them use third-party open source projects or even common libraries within our organization as dependencies.

Should we include the full projects of these dependencies in our various solutions? Or should we just include the .dll reference (or equivalent compiled binary) and maintain the source for said dependency elsewhere (say, for debugging purposes only)?

I'm specifically thinking of .NET projects and solutions in Visual Studio, but feel free to replace those terms with JAR or whatever equivalent in other languages and frameworks.

To further specify, I'm asking if a [fictional] Invoice Payments Web App solution tree should look like this:

  • InvoicePaymentsWeb
  • InvoicePaymentsDataModel
  • InvoicePaymentsServices
  • RickSoftUltraDataGrid
  • MyCompanyCommonWebLib

And you could individually compile (or change) the various dependencies since they exist entirely within your solution. As opposed to just having the first three projects, referencing the compiled DLLs of the other two, and having the source for the other two exist elsewhere on your machine (or elsewhere in source control).

I'm wondering if this wouldn't potentially fracture the development and/or maintenance of the various dependencies since each solution could have its own specific changes to the source, unless the underlying source control handled sharing the projects internally. What other problems might exist? Would there be any benefit?

Sean Hanley
  • 151
  • 3

4 Answers4

4

Maintaining external sources doesn't really add that much value. If you use particular version of library, it should be enough if you have said binary in your repository. However, if you'll make any changes to library (without making it go live/public - say you needed to add something specific to your company) then it makes sense to have modified sources as part of code base (in fact, you should store them somewhere). If that's the case, such sources should be at top level, just as your libraries directory is:

Invoices
    Invoices.DataAccess
    Invoices.Reports.Templates
    Invoices.View
    Libraries
    LibrariesSources
    ...

Naturally, compiled binaries of changed library would go to Libraries directory and will be referenced from there (as opposed to keeping them in say LibrariesSources\ComplexMath\bin\Release).

k.m
  • 2,162
  • 16
  • 18
2

I always have a "Dependancies" folder that simply has all the dll's.

There is no need to have the full source of third party libraries unless you plan to modify the code in some way specfic to your needs.

Edit: and it should be in source control!

ozz
  • 8,322
  • 2
  • 29
  • 62
  • 1
    This is what I've done, too, and that folder is in source, so that anyone that brings down the solution onto their local machine will be able to build it and not have to go through the "well did you have xyz installed first" dance. – Sean Hanley Apr 17 '12 at 16:37
  • @SeanHanley absolutely, should have said that too, they should be in source control! – ozz Apr 17 '12 at 20:36
1

Here's some pragmatic advice from hard earned experience: don't include whole projects.

That's because IDEs such as Visual Studio or Eclipse (especially Visual Studio) tend to perform really badly when loaded with more and more projects and source code to compile or index.

You're better off just including the DLLs where you need them.

For debugging purposes, you could always keep the code for the library somewhere, and then just open it as a standalone project/solution and attach the debugger to the process that uses that library.

-- Edit

Some people mentioned that it could be a good idea if you plan to modify those 3rd party libraries. I disagree. You don't have to include them in your other solutions to do that. Simply edit them in their own solution, and re-add the newer version.

Yam Marcovic
  • 9,270
  • 2
  • 27
  • 29
0

Source code is useful only when you need to modify something on the third party library. Keeping the binaries on the source control is better than having the whole source code, but using tools like nuget for. Net and mavem for java is much better, because it can resolve the whole dependency tree when you need to update the binaries.

nohros
  • 448
  • 3
  • 9