There should be no problem using a public getter and a private setter. I tried an example before and didn't get the exception you were getting with the old version.
Are you considering upgrading? On Tue, Jul 21, 2009 at 10:36 PM, Michael Yeaney <[email protected]>wrote: > I had originally wanted consumers of the service to be able to talk to the > resolved dependency. For example, we have a WorkQueue<T> class that > internally needs an IDispatcher<T> instance to dispatch work out. I had > wanted consumers of the work queue class to be able to ask the dispatcher > for it's internal state directly (mainly stats), instead of re-exposing the > same information through the work queue itself. Hence, the private setter - > I only wanted external folks to read the data, never set it. > Does this help? > > On Tue, Jul 21, 2009 at 8:05 AM, Jonathon Rossi <[email protected]>wrote: > >> The object not set to an instance of an object exception is a bug, and has >> already been fixed. >> >> However, MK will still set mandatory and optional dependencies even though >> they are the same type. Is there a reason you want a non-private setter when >> the service dependency has already been fulfilled? >> >> >> On Tue, Jul 21, 2009 at 10:25 AM, Michael Yeaney < >> [email protected]> wrote: >> >>> Hi all... >>> >>> Using Castle.Microkernel version 1.0.3.0 (have not upgraded yet), and am >>> experiencing some rather strange behavior with the DefaultComponentActivator >>> class. It seems that if you have a property (optional dependency) with >>> _exactly_ the same name as a constructor arg (required dependency), >>> DefaultComponentActivator will attempt to set the dependency not once >>> through the .ctor, but twice - once through the ctor, and again through the >>> property (via the SetUpProperties method). >>> >>> Normally, this isn't a big issue (although I am a bit curious as to why >>> the dependency is set a second time, after being satisfied through the >>> ctor). However, if the property in question has a private setter (in other >>> words, read-only, so external folks can view inside the object but not set >>> it), the Resolve<T> method will raise an "Object not set..." exception, even >>> though the constructor has already been run and the component is alive. >>> >>> Is this a known issue with 1.0.3.0? If it's not a bug, can somebody >>> explain the logic behind this? >>> >>> Cheers! >>> Michael >>> >>> >>> >> >> >> -- >> Jono >> >> >> > > > > -- Jono --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
