Sorry was not suggesting MEF supports remove as such, just that mechanisms like re-composition seem more suited to those scenarios then say Windsor is.
Restarting the application (or at least disposing/recreating the container) is the only truly consistent approach I can see, especially where life styles other then transient are being used. Oh and child containers - though wasn't there some debate about there future as well? 2010/8/29 Ayende Rahien <[email protected]> > FWIW, I don't think that MEF gives you the ability to unload a component > > 2010/8/29 Alex Henderson <[email protected]> > > We use it currently in a product where we have plugins that register >> services in the container, and those services can be unregistered (if the >> plugin is removed/disabled) which will effectively undo all the >> registrations via remove in reverse order. >> >> Though we currently haven't phased it out, we plan to end of life this >> live disable functionality in favour of restarting the entire application >> when one or more plugin removals/disable actions takes place (like how say >> Hudson does it) - because of the aforementioned problem - 9 times out of 10 >> it will throw an exception when attempting to remove a component anyway due >> to interdependencies. >> >> The use cases for remove tend to suggest something like MEF instead of >> Windsor I think - So I'm happy for this functionality to be removed, even >> though we do (kinda) currently rely on it. >> >> Cheers, >> >> Alex >> >> 2010/8/29 Krzysztof Koźmic <[email protected]> >> >>> Hey guys. >>> >>> >>> I'm looking at some more serious modifications that we could do for >>> Windsor 3.0 and one thing that I'd really like to get rid of is >>> IKernel.RemoveComponent (not to be confused with IKernel.ReleaseComponent or >>> IWindsorContainer.Release). I'm talking about method that is the opposite of >>> Register, not Resolve. >>> >>> The method is very flawed, not thread safe, has bugs, its usability is at >>> best questionable and getting rid of it (so that I can make an assumption >>> that once a component is in the container it can not dissappear) would >>> enable me to get rid of lots of code and make some performance >>> optimizations. >>> >>> So my question is - what do you think about this idea - did anyone of you >>> ever really used this? If so - why and for what? >>> >>> feedback greatly appreciated, thanks >>> >>> -- >>> 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]<castle-project-users%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/castle-project-users?hl=en. >>> >>> >> -- >> 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]<castle-project-users%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/castle-project-users?hl=en. >> > > -- > 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]<castle-project-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/castle-project-users?hl=en. > -- 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.
