ninject / ninject.extensions.namedscope

This extension allows that bindings can define scopes. All dependencies can now define that they want to use this instance as their scope.

Ninject

Ninject is a lightning-fast, ultra-lightweight dependency injector for .NET applications. It helps you split your application into a collection of loosely-coupled, highly-cohesive pieces, and then glue them back together in a flexible manner. By using Ninject to support your software's architecture, your code will become easier to write, reuse, test, and modify.

Write your code so it's flexible...

public class Samurai {
    public IWeapon Weapon { get; private set; }
    public Samurai(IWeapon weapon) 
    {
        this.Weapon = weapon;
    }
}

...and let Ninject glue it together for you.

public class WarriorModule : NinjectModule
{
    public override void Load() 
    {
        this.Bind<IWeapon>().To<Sword>();
    }
}

Features:

1. Focused. Too many existing dependency injection projects sacrifice usability for features that aren't often necessary. Each time a feature is added to Ninject, its benefit is weighed against the complexity it adds to everyday use. Our goal is to keep the barrier to entry - the baseline level of knowledge required to use Ninject - as low as possible. Ninject has many advanced features, but understanding them is not required to use the basic features.

2. Sleek. Framework bloat is a major concern for some projects, and as such, all of Ninject's core functionality is in a single assembly with no dependencies outside the .NET base class library. This single assembly's footprint is approximately 85KB when compiled for release.

3. Fast. Instead of relying on reflection for invocation, Ninject takes advantage of lightweight code generation in the CLR. This can result in a dramatic (8-50x) improvement in performance in many situations.

4. Precise. Ninject helps developers get things right the first time around. Rather than relying on XML mapping files and string identifiers to wire up components, Ninject provides a robust domain-specific language. This means that Ninject takes advantage of the capabilities of the language (like type-safety) and the IDE (like IntelliSense and code completion).

5. Agile. Ninject is designed around a component-based architecture, with customization and evolution in mind. Many facets of the system can be augmented or modified to fit the requirements of each project.

6. Stealthy. Ninject will not invade your code. You can easily isolate the dependency on Ninject to a single assembly in your project.

7. Powerful. Ninject includes many advanced features. For example, Ninject is the first dependency injector to support contextual binding, in which a different concrete implementation of a service may be injected depending on the context in which it is requested.

Everything else is in Extensions

Yes, sounds slim and focused, but where is the support for all the features that the competitors have?

Generally, they are maintained as specific focused extensions with owners who keep them in sync and pull in new ideas and fixes fast. These are summarized on the extensions section of the project website. Most are hosted alongside the core project right here.

License

Ninject is intended to be used in both open-source and commercial environments. To allow its use in as many situations as possible, Ninject is dual-licensed. You may choose to use Ninject under either the Apache License, Version 2.0, or the Microsoft Public License (Ms-PL). These licenses are essentially identical, but you are encouraged to evaluate both to determine which best fits your intended use.

Refer to LICENSE.txt for detailed information.

Changes history

• Changes in Ninject 3
• Changes in Ninject 2
• Detailed change log

Resources

• Project website
• Documentation
• Wiki
• Nate's blog
• Ian's blog
• Remo's blog

ninject.extensions.namedscope's Issues

Issue with COM Interop

I realize COM interop makes this fairly obscure. But I'll report it anyway.

I have a classic ASP project that needs to talk to some .NET code. I expose this via a 64-bit COM interop assembly.

It's been working fine for years. Today I updated a ton of NuGet packages and, suddenly, any attempt to create the COM object results in error 0x80131534 "Server.CreateObject failed". I tried from other VBScript hosts (cscript) and got the same error.

After painstakingly backing out the updated NuGet packages one at a time, I traced the problem to Ninject.Extensions.NamedScope.

I use InCallScope in one binding in the static initializer for my COM class. If I simply remove the call to InCallScope, the error doesn't happen. If I revert back to 3.2, it doesn't happen. It only happens with 3.3.

If using 3.3 and the call to InCallScope is present, the static initializer doesn't even run. The error occurs before any of my code runs. I tried, for example, wrapping the binding in a try/catch, but the error still happens.

Now, here's the really weird part: if I just copy the code for this extension into the DLL and remove the reference to the Ninject.Extensions.NamedScope package, there is no error. As such, it seems to me that this is some sort of issue with the DLL binary, not the code itself. Because of the COM system's less-than-helpful error messages, I'm unable to make any guesses beyond that.

I have a workaround for now -- i.e., copy the code into the DLL -- but I thought I'd put this out there in case it's indicative of some other problem.

Should parent object must be derived from DisposeNotifyingObject?

Hi @remogloor , a quick question: should the parent object must be derived from DisposeNotifyingObject?
I saw most of the fake parent types in unit test are derived from DisposeNotifyingObject and when I removed the inheritance, the UT failed.

Maybe an Issue on the Nuget packages

I tried Install-Package Ninject.Extensions.NamedScope on Nuget Console. The installed package give me error when I use DefinesNamedScope(). It says IBindingWhenInNamedWithOrOnSyntax cannot be inferred to IBindingOnSyntax`1

Then I installed the package with
Install-Package Ninject.Extensions.NamedScope -Version 3.2.0. The error does not exist any more.

Named scope throws ScopeDisposedException when using "Release" configuration

Using named scopes in code built using "Release" configuration can cause scope objects to be disposed of and garbage collected prematurely, which in turn causes ScopeDisposedException to be thrown. This issue does not manifest itself when using "Debug" configuration.

Here's a sample binding configuration that allows this to happen:

Bind<IMainProcessor>().To<MainProcessor>().DefinesNamedScope("TheScope");
Bind<ISecondaryProcessor>().To<SecondaryProcessor>();
Bind<IDataFactory>().ToFactory();
Bind<IData>().To<Data>().InNamedScope("TheScope");

Main method retrieves MainProcessor via Kernel.Get<IMainProcessor>(). ISecondaryProcessor is passed to MainProcessor via constructor injection, and IDataFactory is passed to SecondaryProcessor via constructor injection. Then, inside SecondaryProcessor, IData objects are obtained using factory method.

If GC occurs while SecondaryProcessor works on its IData object(s) in a loop, GarbageCollectionCachePruner will kick in and collect the named scope reference object. This results the subsequent request to retrieve IData using factory methods to fail, and ScopeDisposedException to be thrown.

Changing the binding setup by moving the DefinesNamedScope("TheScope") declaration to the SecondaryProcessor's binding seems to work in this case, but it's not a viable solution, as multiple SecondaryProcessor instances, that need to share the same IData object, might need to be created.

A Visual Studio solution illustrating this problem can be downloaded from here: http://s000.tinyupload.com/index.php?file_id=60787475607892861020
Behavior can be reproduced by first building the solution using "Release" configuration, and then running the executable without debugger attached (e.g. using windows explorer).

Binding an IService to an implementation in Parent scope throws on a call to IResolutionRoot.Get<IService>()

In this case, there is no parent scope. I'd like to bind IDisposable's in parent scope so they are disposed when their parent is collected. But, I may also need to get IService via IResolutionRoot.Get() outside of any parent scope. I understand there is no parent scope in this case and I'm responsible for disposal.

Ninject throws a null reference exception in this case.

Ninject version: 3.0.1.10
NamedScope extension version: 3.0.0.5

Replication steps:

• Create an interface IService
• Create a class implementing IService
• Bind IService to the class in parent scope
• Call IResolutionRoot.Get()

Exception lacks important information

When using Ninject.Extensions.Factory autogenerated factories together with the namescope extension, a binding with faulty scope settings might generate an exception as follows:

 Ninject.Extensions.NamedScope.UnknownScopeException: The scope 
     SomeScope is not known in the current context.
 at Ninject.Extensions.NamedScope.NamedScopeExtensionMethods
     .GetScope(IContext context, String scopeParameterName)
 System.Exception {Ninject.Extensions.NamedScope.UnknownScopeException.

Given only this exception message, it is really hard to find out where the problem lies. An exception message such as in normal ninject binding failures would greatly improve the situation.

NamedScope was not found when using Inject() or Get<IService>() after initial injecting

Ninject.Bind().To().DefinesNamedScope("#window");
Ninject.Bind().To().InNamedScope("#window");
Ninject.Bind().To().InNamedScope("#window");

then whenever i call:

var window = Ninject.Get();

and each created window object has its own instance of IToast and ITaskManager. its Ok.

later in program in instance of ITaskManager user exectutes newTask() method and within

new Task will be created of type:

`public class Task
{
[Inject]
public IToast Toast {get;set;}

[Inject]
public ITaskManager {get;set;}
}`

using normal Contructor (var task = new Task() ):
and then:

Ninject.Inject(task) excepts :

says named scope "#window" is not found.

Identity Scope

@remogloor Is there a way to later evaluate a named scope?

class Foo()
{
    public Foo(string bar)
    {
    }
}
class Service()
{
    public Service(Func<string,Foo> fooFactory)
    {
        var f1 = fooFactory("A");
        var f2 = fooFactory("A");
        var f3 = fooFactory("B");
        Assert.AreEqual(f1,f2);
        Assert.AreNotEqual(f1,f3)
    }
}

Ninject 3.3.1

Hi,
We are upgrading to Ninject 3.3.1.
Is there a plan to have this extension support latest Ninject version?

Current dependency is shown as Ninject (>= 3.2.0 && < 3.3.0)

thanks

Why NamedScopeParameter Have ShouldInherit false

Hi,

I was getting an error creating NamedScopes When Injecting IResolutionRoot inside nested clases. ContextPreservation wraps the request and don't inherit parent context parameters. All of this get solved, in my case, by changing ShouldInherit to true when creating the NamedScopeParameter.

The Problem is that ShouldInherit is set hardcoded to false. There is a collateral effect on changing this to true, or at least making configurable from whom creates the namedscope?

Thanks.

3.0.2 Stable NuGet package?

Is there any reason why 3.0.2 isn't stable on NuGet?

We're trying to generate stable NuGet packages internally but need to use the unstable NamedScope extension (for the NamedScope creation method that doesn't appear in 3.0.0.5 - the last stable version on nuget.org). It seems if a dependency is pre-release then the package gets labelled as pre-release.

Is there a genuine concern that 3.0.2 isn't stable?

Cheers,

James

Why NamedScopes invoke dispose methods from finalizer?

I noticed that when I use IDisposable objects inside Ninject named scope my Dispose method is called from finalizer. But my object or some of it references may be already finalized at that point.

Am I missing something? Is it a correct behavior or a bug?