Introducing NHibernate 3.0

I don't know since when too many assemblys/projects becomes a sin - it's a good way to control dependencys. Face it, there are way too many primary programmers than qualified ones, and by using different assemblys you can force some dependecy rules.
For projects like NH, it might make sense that after build, there is a merge process to merge them to one, but I really don't think just namespace is good enough to control this.

I personally have a black and white view on this matter. If you can bundle everything into a single EXE, awesome. If not, you need an installer anyways and all those extra assemblies just make partial builds faster.

But to be fair, Patrick Smacchia probably has a heck of a lot more experience analyzing .NET projects than I do.

monser corp please don't foster what I consider the most harmful anti-pattern in the .NET real-world of development.
There are tools to check dependencies, NDepend of course, but also VS 2010 Ultimate and certainly some others tools.

I literally have seen dozens of projects rooted just because they had hundreds of VS projects and assemblies. Treat assemblies for what they are: a physical mean to package code. Checking dependencies with assemblies, is treating them as a logical means.

Jonathan pinpointed a great advantage of having just one assembly: deployment is made easier. But there are two even better advantages of keeping the number of assemblies small:
- physical organization of the code sources is made much easier
- compilation time is decreased dramatically, it can be in order of magnitude.

Dear reader, I confirm, by having few assemblies, your big project you are working can be compiled in just a few seconds on your workstation instead of several minutes!

I have written a post on this, and plan to polish it into a white book:
codebetter.com/patricksmacchia/2008/12/08/advic...

The slow compilation issue sounds like a platform issue. If this forces you to use a "poor" architecture, then you are using the wrong platform.

From my experience, having more "assemblies" actually forces better code organization. It is much easier to combine code than it is to break it apart. It makes you have cleaner APIs. If you can combine multiple Projects into a single assembly (I don't know and have not tried) then that will solve some of the issues, but might cause others.

Code should be organized based on reasons _other_ than what you listed. If only one assembly is needed, then only create one.

I agree that misuse assemblies for bad reason are bad, like anything is misused, and your statement gave me the impression that more than 1 assembly is bad. Neither do I agree that assembly is the "most harmful anti-pattern" (what's wrong with implementing logical rule with physical purpose?). I would say some C# language features are create much more bad samples than .net assemblies. For development, the most important is to prevent poor developers from shoting themselves or their teammates. Some times your biggest enemies are your team members. Maybe you are lucky enough to live in a team that have same level as you are and most of them produce good or normal codes. But I don't belive most of developers are as lucky. I once read a statement (can't remember from whom, from uncle bob?) saying most of the project's codes are written by the 2nd worst programmer. Because the good programmers are focusing on the worste ones. And unfortunately my unlucky experience confirmed the statement again and again. I would use whatever it takes to prevent programmers to make mistakes. I would consider the other factors after I've got clean codes.

Personally I would say that compilation performance reason is not so relavent. Pepole who write bad codes does not care waste several mintes on compiling, and I guess those guys have never heard about continous integration or unit testing. Peple who write bad codes does not care about deployment. They have managed to servive (or create?) the dll hell, definitely they'll servive again .net's xcopy deployment.

Agreed. Clear architecture is more important and some times can be hinted by cycled assembly reference (I recently got one), this will not easily be detected by simple namespace dependecy detection. On the other hand, I would try to prevent errors if possible than detecting errors.

If you want to minimize your assembly numbers, there is a tool, ILMerge which does it. (as long as you don't use too much reflection, it works very good, at least you can merge those static ones in one assembly).

I m with monser corp it happens,but I wanna add something like its not all responsibility of developers its a push from organizations , they need every thing in Eye flash.
I am trying to implement it in my organization but problem is developers are capped because of business management pressure.