I remember the time when I have removed the reference to Castle from NH-Core. The advantage was clear for who, like me, was a Castle-trunk user: no more egg and chicken problem (aka bergamotta circular)
The wrong decision, at the time, was to force a new property configuration... probably I'll remove this constraint in a way or another without force a default. For what I saw in my work, at least 90% of application, using NHibernate, are WEB applications. At least 90% of those WEB application are using Castle.DynProxy2 as dyn-proxy system. So far, for NH3 they will have to deploy: NHibernate, Iesi.Collection, re-linq, Antlr3, NHibernate.Bytecode.Castle, Castle.Core, Castle.DynProxy2 and log4net 8 DLLs only because NHibernate To give support to Client-Profile we will have: NHibernate, Iesi.Collection, re-linq, Antlr3, NHibernate.Bytecode.Castle, Castle.Core, Castle.DynProxy2, log4net and NHibernate.Web, Common.Logging, Common.Logging.Log4Net and configuration of common logging in web.config (note : they should download Common.Logging.Log4Net from another site). We will make happy at most 10% of users (supposing that all no-web applications are interested in client-profile-support) and we will hurt 90%. Instead reduce NH's external-dependencies we will change one with another and I can't see where is the benefit. Note: many NH's user are using NHProf, someone are using NHTrace (both based in log4net), some other use directly log4net and probably mostly does not activate the logger. Even if I think that we don't have to reinvent the wheel, I'm inclined to use our solution removing the dependency to log4net but distributing a NH version with a log4net adapter merged. That's my thought. -- Fabio Maulo
