Question

My question is in regard to referencing open source frameworks. There are many of them for many different purposes. I personally leverage several of them in a single project. For example:

1. Unity
2. CAL/Prism
3. ValidationAspects
4. EnterpriseLibrary Logging
5. EnterpriseLibrary Exception Handling
6. EnterpriseLibrary Caching
7. Caliburn

All of these frameworks have helped greatly from a development effort perspective. There are however some negative aspects involved:

1. Tons of dlls (15 from the above list).
2. Application level (non-common assemblies and new assemblies) must reference many core dlls, which can be confusing) and tons of different namespaces are involved.
3. Deployment of said tons of dlls can get problematic (I sometimes use ILMerge to alleviate this and the above problems, but let’s put that aside for now).
4. Open source project lifetime – open source projects come and go, so if any of these become no longer actively maintained, it can be concerning if there are internal bugs that need fixing or enhancements we want.
5. Obfuscation of “how to do things”. We don’t actively leverage every part of the above frameworks. In fact, several of these frameworks have overlap and provide redundant components and functionality. In terms of development, this can be confusing. We want a consistent implementation that is straightforward and easy to understand across our code base. Having multiple areas that do the same thing in different ways can be troublesome in this respect. This is probably one of my biggest concerns.
6. You’re in big trouble if these frameworks reference different versions of other assemblies (ie. one internally references Unity 1.1 and another Unity 2.0).

The alternative? Include the source code in a common dll for your project(s) (ie. MyProject.Common). Let’s put aside the issue of adherence to license requirements for the time being.

This has several negative implications too:

1. It’s not as easy to leverage updates released by the framework’s provider – you need to update your source code.
2. Encapsulation of functionality – it’s easier to break this paradigm when the source code is all in your hands.

So, I know people probably have lots of opinions on this…and I’d like to hear them.

Thanks.

Answer 1

For some aspects of your problem, this might be relevant: http://en.wikipedia.org/wiki/DLL_hell#Running_Conflicting_DLLs_Simultaneously.

Another common solution to this problem is to write an encapsulation layer on top of the functionality needed, which at least protects your code from wild changes when upgrading to new versions of supporting libraries.

As to open source project lifetime, it should be clear which projects are healthy and which are not. For example, a project that is part of the Apache or Eclipse foundations are probably healthy, whereas some random thing on sourceforge is probably not. Generally, you can avoid this problem altogether by avoiding projects that do not seem active.

For the negatives to copying code into your project:

1. I know you wanted to put license aside, but you cannot in reality. I am not a lawyer and you should consult with one for your project if there may be issues, but if you are developing a proprietary system it could become GPL’ed accidentally.
2. It makes your development environment more cluttered. You have to worry about making sure the copied-in code ompiles properly, is being compiled with the right version, and has the right build scripts. You also have all this extra code in your IDE that takes up space.
3. As you pointed out, it makes updating code very difficult.
4. If you have to file bugs with the Open Source project, it becomes more difficult to do.
5. If you’re not careful, a junior developer who doesn’t know any better could go into the code and start mucking around with it.

There’s probably more reasons not to do it, but that’s a few. Hope that helps.