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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
