Hi, I have found the cause. It might be obvious to everyone here, but wasn't for me. Castle documentation says it: ==== This usage is not useless, in fact it's a good option if you plan to use an IoC container as the application rendesvouz. Just be aware the if you're using the container on the server endpoint, the components published, when requested by the client endpoint, will be server directly by .net remoting. Castle will not be able to intercept it. This might be undesired if, for example, you're using the NHibernate facility to provide automatic session creation and disposal, or the Automatic Transaction facility to manage transactions. Even auto wire is not going to work. ==== It appears that I were bypassing the container... So, basically, the documentation says that if you want to expose your components for remoting using the remoting facility, you have to use Castle on client side, otherwise you'll get very odd results. And I don't think this is a 'good option', basically because if you use plain .Net remoting on client side you are losing all the benefits Castle IoC provides. Would it be very hard to modify the remoting facility so it could intercept remoting requests and allow the container to satisfy the dependencies both for local and remote access?
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en -~----------~----~----~----~------~----~------~--~---
