Awesome news... but without field injection there is no way to inject properties into object created by someone else.
Nate Kohari
· 10 months ago
I *could* re-implement field injection with reflection only, if it's a feature that enough people care about. It's just really not a good idea to use it. :)
Michael Hart
· 10 months ago
I feel like a kid at Christmas with the anticipation :-)
Am using it now without issue, bar the implicit ASP.NET MVC controller binding issue I tweeted about - it feels beautifully light, a floating piece of elegance.
Well done!
Romain Verdier
· 10 months ago
Hey, that's a good news!
Thanks for your work.
Yann Trevin
· 10 months ago
Is there a dedicated build forseen for the Compact Framework v3.5 (like there is one for NInject 1.0), or is NInject 2.0 of the kind "One-Size-Fits-All"?
Simone
· 10 months ago
Ops... I misread the post... Field Inject DO is bad... I thought you were removing Property injection... sorry for the confusion
Frank Quednau
· 10 months ago
From my perspective, excellent decisions all along. The missing Multi-Inject was rather painful and I am glad it's coming. Everything else sounds very nice. Looking forward to what you're rolling out :)
Adam
· 10 months ago
Support for CF was one of the things that drew me to Ninject in the first place. I like the idea of only having to deal with one IoC across the full framework, SL and CF. So consider this a +1 vote for CF support.
Other then that, all the changes you've made sound awesome and I can't wait to try it out, and also take a look at the source to see how you accomplished it.
Thanks for a great IoC.
Adam
Justin Etheredge
· 10 months ago
Nate, you are the man! Looking forward to seeing Ninject grow in the future.
Thomas Skovsende
· 10 months ago
I'm a bit bummed about the loss of AOP - how much do I have to scream to get that in? ;)
Or, is it because of your lack of time it's not there, or is it because it would be hard to add to Ninject2?
tobsen
· 10 months ago
Well, I like the field injection feature of Spring when using 3rd Party components which have not the setters I need. However I think this is only rarely needed. Thanks for the Common Service Locator support!
Dave
· 10 months ago
Please don't add support for private member/field injection in Ninject 2. As the post says private member/field injection is a bad habit.
IoC should be used to make projects more maintainable (readable). Someone new to a project might have a hard time figuring out where that dependency comes from. When you have a property it's instantly clear that the dependency is assigned.
Devvers who don't want that other components (if the class itself ins injected into other parts of the application) use the injected classes should use setter-only properties or a method marked with the Inject attribute.
And besides that. Don't you think you also have a moral tasks to prevent users of Ninject to make stupid decisions like using field injection ;-)
Peter Meyer
· 9 months ago
Nate,
Any plans to include WCF extensions (i.e. ServiceHost and behavior capable of DI) with Ninject 2?
You've a great library here. Looking forward to taking a look at Ninject2.
Thanks for the effort so that we may benefit.
Pete
Bill
· 9 months ago
2.0 sounds very exciting, but support for CF is a definite must.
PandaWood
· 8 months ago
The codebase I'm working on that works with Ninject1, throws with Ninject2.0 beta. I can't work it out why (System.ArgumentException: Expression of type 'System.TimeSpan' cannot be used for return type 'System.Object') I'll have to bail on using it, as I need to get some work done. But will come back to it and see if I can help figure it out.
Ben Ellis
· 7 months ago
[quote]If no constructors have an [Inject] attribute, Ninject will select the one with the most parameters.[/quote]
What's your reasoning for changing this behaviour? It seems to me to cause problems since several implementations of IMyInterface may have completely different constructor parameters.
Is there a way to change it back to the original behaviour of using the Default Constructor if no [Inject] attribute is applied?
Eric
· 7 months ago
Nate,
We chose Ninject because of its .NET CF support. We love it, but really need the multi-injection support. Please keep CF support as the valuable feature it is.
Thanks, Eric
Ross
· 7 months ago
Ninject 2.0 has some great features we've been looking for including Multi-Injection. However one of the reasons we chose Ninject was due to the CF support. Please add CF support to 2.0!!
Eric Hamrick
· 7 months ago
Another person using Ninject 1.0 on mobile devices. Hoping to see 2.0 supported on CF as well. :)
Eric
Steven H
· 5 months ago
Please, dont drop CF support - Think about the children !!!!!!!
Justin
· 5 months ago
Nate, I was actually getting ready to adopt unity for an IOC due to its service locater support. Great to see this will be in Ninject 2! Do you have a release date yet for v2?
Urs Enzler
· 4 months ago
I just started using NInject and refactored a very small test application from Unity to NInject 2. The first thing I noticed: NInject error messages are far better than the cryptic error description of Unity. So, after spending about 15 minutes refactoring, all is up and running. Really cool!
As others stated, I'd be glad if CF support would stay in. The reason is, that our company has a lot of "normal" .net projects as well as CF projects, and we like to be able to reuse our stuff and therefore the injection container.
All Comments
Amazing stuff! keep it up
but without field injection there is no way to inject properties into object created by someone else.
Am using it now without issue, bar the implicit ASP.NET MVC controller binding issue I tweeted about - it feels beautifully light, a floating piece of elegance.
Well done!
Thanks for your work.
I thought you were removing Property injection...
sorry for the confusion
Other then that, all the changes you've made sound awesome and I can't wait to try it out, and also take a look at the source to see how you accomplished it.
Thanks for a great IoC.
Adam
Or, is it because of your lack of time it's not there, or is it because it would be hard to add to Ninject2?
Thanks for the Common Service Locator support!
IoC should be used to make projects more maintainable (readable). Someone new to a project might have a hard time figuring out where that dependency comes from. When you have a property it's instantly clear that the dependency is assigned.
Devvers who don't want that other components (if the class itself ins injected into other parts of the application) use the injected classes should use setter-only properties or a method marked with the Inject attribute.
And besides that. Don't you think you also have a moral tasks to prevent users of Ninject to make stupid decisions like using field injection ;-)
Any plans to include WCF extensions (i.e. ServiceHost and behavior capable of DI) with Ninject 2?
You've a great library here. Looking forward to taking a look at Ninject2.
Thanks for the effort so that we may benefit.
Pete
I'll have to bail on using it, as I need to get some work done.
But will come back to it and see if I can help figure it out.
What's your reasoning for changing this behaviour? It seems to me to cause problems since several implementations of IMyInterface may have completely different constructor parameters.
Is there a way to change it back to the original behaviour of using the Default Constructor if no [Inject] attribute is applied?
We chose Ninject because of its .NET CF support. We love it, but really need the multi-injection support. Please keep CF support as the valuable feature it is.
Thanks,
Eric
Eric
As others stated, I'd be glad if CF support would stay in. The reason is, that our company has a lot of "normal" .net projects as well as CF projects, and we like to be able to reuse our stuff and therefore the injection container.
Keep up the great work
Cheers
Urs