1. Integration code: code to ‘glue’, say, Wicket to Spring to Hibernate. Separate project, new projects just import the binary. Should be minimal and stable. No forks.

2. Common components: rich components that don’t exists in open source libraries. Separate project, may import (1), new projects import the binary. Grows as time goes, without affecting the core (1). New projects may fork components to adapt them to their contexts, if really necessary.

3. Common code that is very likely to change: base templates, configuration, css files, etc. Separate project, copied source. If I use Maven as build tool, it may be an archetype (a kind of quickstart code generator).

This structure keeps the core stable, what makes the chances of breaking stuff lower. Components are shared, but any major flexibility needs are satisfied by forking some code., These components should be kept as much ‘vertical’ as possible, without too much dependencies between them. And, the code that every project has to write again and again (very similar, but tweaked to the specific application) is just copied and never breaks other projects.

It’s very tempting to just say “Centralize! DRY! Are you stupid or something? It’s so obvious!”, but dependencies and version control is not a problem you can take lightly. And keep ‘one framework to rule them all’ IS a very difficult and painful task. But sometimes necessary. My answer to this is to make this framework as little as possible, to minimize this pain.

Well, for now, I guess

It is entirely possible that this only works because of the way we reference our common code: ‘client’ projects reference the build output of our common code. We don’t check the binaries into source control, so it means each developer has to build the common project. This, however, comes with its own bag of issues.

We started off looking at the Global Application Framework To End All Frameworks but quickly realized that this wasn’t going to be productive – and instead changed that into a collection of common library components, minimizing or removing dependencies on each other. So you can pick and choose the components a la carte as suitable for the project. For example, assemblies for Windsor or for Spring.Net.

This reduces (but does not eliminate) one of your Cons for option 1 – “The infrastructure code has to have a lot of extensibility points “.

It also helps with a problem of the Global Framework – you have Project X that could use 99% of whats in the GloboFramework, but due to one little thing like they use a slightly older build of NHibernate, you can’t include the GloboFramework dependencies at all.

yes and yes

Option 1) Do you mean that
The infrastructure code is in a project on it’s own, you build it. And in your multiple solutions, you add a reference to the build assembly?

Option 2) Do you mean that
The infrastructure code is in a project on it’s own, but you include the project and source in your multiple solutions and build the infrastructure with the rest of your solution?

I generally tread carefully around the concept of a “framework”. I prefer more of a common component library or service provider approach. Frameworks are like closet organizers. They’re conceived to be infinitely flexible, built to the dimensions of a rather confined space, and before you know it you’ve got “something” but with nowhere to put your socks.

We currently have over 20 different applications running off of one framework. The fact that they all reference the same libs means that our build process can build a new framework version, and all apps on that framework, and tell us when we did something stupid.

The other thing is we have a ‘Deploy’ target in our framework project files, so no auto deployment by accident happens. Crutial when working on the framework libs themselves.

i actually prefer to use a ‘lib’ folder for each project where i keep all of the binary dependencies… dependencies are something i’d much rather upgrade manually than getting caught off guard by some kind of automatic update which could break things unexpectedly