Ninject 3.3 beta1 has gone live. This release mainly focus on bug fix and platform update.
Support .NET Standard 2.0
Since version 3.3, Ninject starts to support .net standard 2.0. Microsoft announced .net standard 2.0 at Augest 14th which has more than doubled the set of available APIs. It makes much easier to port Ninject to .net standard 2.0. Previously there are many conditional compilations and even wrong behaviors during 4.0 pilot development. For example ReflectedType is not supported in .NET Standard 1.5. The workaround is to use DeclaringType. However DeclaringType is different with ReflectedType. So in release 3.3, we only support .net standard 2.0 and .net framework 4.5. The only difference is the auto module scanning feature. net framework supports to create and unload AppDomain while .net standard 2.0 doesn‘t.
Ninject 3.3 also dropped support for .NET 3.5 and Silverlight.
Array/List of concrete classes will return empty if the concrete class is not explictly binded
The is a behavior change. If a concrete class is self bindable, but user didn‘t bind it explicitly, when request a list of it, it is more naturally to return an empty list rather than a list with one item. This should be a break change. But I think it is a correct move.
Improved cyclical dependencies detection
The cyclical dependencies detection has been improved for open generic types. Check the github issue for details.
Conditional binding is being considered when score constructors
When score constructors, previously, we will look for the one with most bindings matching regardless the binding condition.
consider the below case:
[Fact]
public void UnsatisfiedConditionalShouldBeIngored()
{
kernel.Bind<Barracks>().ToSelf();
kernel.Bind<IWeapon>().To<Sword>();
kernel.Bind<IWarrior>().To<Samurai>().When(_ => false);
var barracks = kernel.Get<Barracks>();
barracks.Should().NotBeNull();
barracks.Warrior.Should().BeNull();
barracks.Weapon.Should().NotBeNull();
}
Barracks has 3 constructors, one with IWeapon, one with IWarrior, one with both. It should choose the one with only IWeapn. So please be advised that the condition method will be evaluated twice now.
Singleton / circular dependency
When request a singleton object which has property dependencies (or has OnActivation callback), during creating the dependecies (or executing the callback), the singleton object may have already created. In this case we should return the created singleton object instead of creating a new one.
Check this commit for details.
Other changes
There are some other bug fixes and changes. For example some spelling correction in xml doc comments; start to use Appveyor as CI build server; Start to use CodeCov to track the code coverage; StyleCop compliance.
For the complete change list, please refer to the ReleaseNotes.md and commits.
Happy Injecting!