Ayende just brought up the issue of project structuring, and his experience was so similar to mine that it cannot be a coincidence.
In my old job I spent a lot of time trying to "do things properly". Splitting up into a lot of logical assemblies, promoting reuse by having special helper assemblies and so on. The result was a huge amount of lugggage that each application had to carry around. When we deployed a simple windows service or console program, it consisted of 9 or 10 assemblies. And don't get me started on versioning all of these, because we were very methodical there too. It sort of worked, but only because we had build a very rigid CI monster controlled by a horde of NAnt scripts that no one - even me who wrote most of them - could figure out after two months away from them.
Today I consider that a learning experience, and I go for the "three project solution". Ayende says two, but I think having a third is worth the hassle. Especially when you create solutions that have different application components in a workflow.
The three projects goes a little something like this:
- Application.Core : Holds all the logic and data for the solution. I split up classes in a logcal folder/namespace structure. As I favor using MVC pattern a lot, it usually holds Model, Controller, DataAccess and Helper folders.
- Application.Core.Test: A test library for the core lib, same structure as the Core.
- Application.<Type>: This is the application itself. The type can be Website, ConsoleApp, Service or whatever it is that I am creating. If there are more apps, there usually is, they get their own projects. All application projects have as shallow code as is can - usually only the View parts of the MVC structure.
I find that it reduces friction both when developing, but especially when deploying. Only two assemblies to deploy. No inter version dependency nightmares and so on. Simple and smooth.