cheers,
@K
On 16/02/2012 11:48 PM, Lundberg, Per wrote:
Hi,
Yeah, that could be an idea. I’m quite busy this week but we could do
it at some point. I’ve added a bug report about it until then.
Best regards,
Per
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of
*Krzysztof Kozmic
*Sent:* den 16 februari 2012 14:41
*To:* [email protected]
*Subject:* Re: Properties in an internal class not being injected,
even though the class is public
Yeah,
please report it. I'm not working with Silverlight but if you want to
pair program on this and look for solution I'm happy to.
@K
On 16/02/2012 10:36 PM, Lundberg, Per wrote:
Hi,
Interesting it does indeed! I didnt think of that myself, because we
never (and I mean really never 0% of the time) use .ctor-based
injection. Instead, we use property-based injection with our own
[Inject] and [InjectOptionally] attributes, which does just what you
would expect them to do :-)
It would be quite interesting to see if this is because of a
limitation in the SL .NET runtime, or if its something that can be
worked around. I think its nice to be able to let our services be
internal, but if that makes the injection silently fail, its no so
nice of course. Please, check it out if you like. (Do you want me to
make a bug report for this also?)
(So, the answer to your second question is implicity yes also.)
Best regards,
Per
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of
*Krzysztof Kozmic
*Sent:* den 16 februari 2012 14:29
*To:* [email protected]
<mailto:[email protected]>
*Subject:* Re: Properties in an internal class not being injected,
even though the class is public
Hi Per,
that indeed is "interesting". Can't say from the top of my head I can
see any reason for it to do it.
If you make it a .ctor dependency does it work?
Also, I know stupid question, but did you register IWindsorContainer
in the container? It's not available by default...
@K
On 16/02/2012 10:23 PM, Lundberg, Per wrote:
Hi!
Ive seen an interesting issue lately which affects how properties get
injected. My registration looks like this (I have to use AllTypes.*
rather than Component.* because Im calling a configuration method to
help out with the configuration, and I couldnt get that working with
the Component.* approach):
windsorContainer.Register(AllTypes
.From(type)
.Pick()
.LifestyleSingleton()
.Configure(c => c.ConfigurePropertyInjection()));
The ConfigurePropertyInjection method basically calls .Properties()
with a predicate, to make certain properties be included as mandatory,
and others included as optional, based on a customer attribute in our
application framework.
The class being registered looks like this:
internalsealedclassInternalEntitiesInitializer: IAutoInitializedComponent
{
///<summary>
///The Windsor IoC container.
///</summary>
[Inject]
publicCastle.Windsor.IWindsorContainer WindsorContainer { get; set; }
Now, the really interesting thing /This works/, when running with WPF.
The WindsorContainer get injected. But with Silverlight, it doesnt. I
presume its because the class is internal, but the thing is that I
have the InternalsVisibleTo assembly property set up so that _it
should work_. And I mean, it finds the type (when registering it), so
why on earth does it ignore its properties? J
Thanks in advance for any help with this.
Best regards,
-- -- -- -- -- -- -- --
*PER LUNDBERG*/Software Engineer
/[email protected]
<mailto:[email protected]>www.ecraft.com <http://www.ecraft.com/>
tel. +358 (0) 20 759 8687
eCraft Oy Ab, Wolffskavgen 36, FI-65200 Vasa
--
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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[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.
--
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.
