simpleinjector Discussions Rss Feed

New Post: LifetimeScoping error in WebApi self hosted app

kavand — Sun, 19 May 2013 12:36:08 GMT

Hey. I read these (+ , + , + and + ) pages, but I connot figure out what should I do.
I have this simple interface and concrete type:

public interface IIdentifierGenerator {
    long Generate(Type type);
    long Generate<TType>(TType type);
}
public HiloIdentifierGenerator : IIdentifierGenerator { /* implementation... */ }

I create this DependencyResolver:

public class SelfHostedSimpleInjectorWebApiDependencyResolver : IDependencyResolver {

        private readonly Container _container;
        private readonly LifetimeScope _lifetimeScope;

        public SelfHostedSimpleInjectorWebApiDependencyResolver(
            Container container)
            : this(container, false) {
        }

        private SelfHostedSimpleInjectorWebApiDependencyResolver(
            Container container, bool createScope) {
            _container = container;

            if (createScope) {
                _lifetimeScope = container.BeginLifetimeScope();
            }
        }

        public IDependencyScope BeginScope() {
            return new SelfHostedSimpleInjectorWebApiDependencyResolver(
                _container, true);
        }

        public object GetService(Type serviceType) {
            return ((IServiceProvider)_container)
                .GetService(serviceType);
        }

        public IEnumerable<object> GetServices(Type serviceType) {
            return _container.GetAllInstances(serviceType);
        }

        public void Dispose() {
            if (_lifetimeScope != null) {
                _lifetimeScope.Dispose();
            }
        }
    }

and I configured my server like this:

            _config = new HttpSelfHostConfiguration("http://192.168.1.100:20000");
            _config.Routes.MapHttpRoute(
                "API Default", "api/{controller}/{id}",
                new { id = RouteParameter.Optional });
            _config.DependencyResolver =
                new SelfHostedSimpleInjectorWebApiDependencyResolver(
                    IoC.Wrapper.GetService<Container>());
            _server = new HttpSelfHostServer(_config);
            /* etc. */

And this is my controller:

    public class IdentifierController : ApiController {

        private readonly IIdentifierGenerator _identifierGenerator;

        public IdentifierController(IIdentifierGenerator identifierGenerator) {
            _identifierGenerator = identifierGenerator;
        }

        public long Get(string id) {
            var type = Type.GetType(id, false, true);
            return type == null ? -1 : _identifierGenerator.GetIdentifier(type);
        }
    }

Now, when I call the action method, I get this error:

It is not safe to use a LifetimeScope instance across threads. Make sure the complete operation that the lifetime scope surrounds gets executed within the same thread and make sure that the LifetimeScope instance gets disposed on the same thread as it gets created. Dispose was called on thread with ManagedThreadId 28, but was created on thread with id 29.

Where am I doing wrong? Can you help please?

New Post: Register an Interface wich implementation's constructor has arguments

The_Chaoz — Sun, 19 May 2013 07:00:45 GMT

Thank you for your answer. I'll try to avoid delegating the creation to the DI container.

New Post: SimpleInjector Prism Bootstrapper

ObsidianPhoenix — Sat, 18 May 2013 10:55:12 GMT

Hi all,

So a colleague directed me towards SimpleInjector after viewing the stats here. He felt it had the right level of features for his MVC project, whilst being among the fastest around.

I'm starting a new prism app (still feeling my way around the basics of prism/MVVM to be honest), but I was wondering if there is a SI bootstrapper around anywhere for Prism?

If not, can someone point me in the direction of where I can see how the bootstrappers are constructed (i.e. what I'd need to do to roll my own).

Thanks
Fergal

New Post: Register an Interface wich implementation's constructor has arguments

dot_NET_Junkie — Fri, 17 May 2013 08:37:58 GMT

View Models are created by your presentation layer (most often your controller, presenter, page, or whatever your pattern you're using) and are filled with data from the model and possibly other sources. Since this View Model class (this data package) is created using (almost) all run-time values, in shouldn't delegate the creation to your DI container. Further more, in general you're not interested to abstract the View Model from your View or Controller, because it is simply a data package.

If you still try this, you will find out very soon that this gets really awkward, and this holds not only when working with Simple Injector, but for all DI frameworks.

But when we ignore the fact that you're dealing with a view model, you can register types with a string parameter as follows (excuse my C#):

container.Register<ISomeService>(() => new SomeServiceImpl("somePath"));

And when you need to supply a runtime value, you can register a factory or register a Func<T> delegate as follows:

container.RegisterSingle<Func<string, ISomeService>>(
    path => new SomeServiceImpl(path));

New Post: Register an Interface wich implementation's constructor has arguments

The_Chaoz — Fri, 17 May 2013 01:51:38 GMT

Well I read the documentation but I couldn't find how to do this.
I've for example a class called "DocumentViewModel" wich constructor is something like:

Public Sub New(ByVal filepath As String)
    _filepath = New FilePath(filepath)
    //more code...
End Sub

How should I register this? And how should I implement this?

Thanks in advance

New Post: Can Simple Injector support Web API and MVC Controllers simultaneously?

Sergeir — Mon, 13 May 2013 20:17:07 GMT

Thanks! - Adding the additional SetResolver call did the trick! Here is my final code:

  public static class SimpleInjectorInitializer
    {
        /// <summary>Initialize the container and register it as MVC3 Dependency Resolver.</summary>
        public static void Initialize()
        {
            var container = new Container();

            // register Web API controllers (important!)
            var controllerTypes =
                from type in Assembly.GetExecutingAssembly().GetExportedTypes()
                where typeof(IHttpController).IsAssignableFrom(type) // (typeof(IHttpController).IsAssignableFrom(type) || (typeof(IController).IsAssignableFrom(type) && type.Name != "HelpController"))
                where !type.IsAbstract
                where !type.IsGenericTypeDefinition
                where type.Name.EndsWith("Controller", StringComparison.Ordinal)
                select type;

            foreach (var controllerType in controllerTypes)
            {
                container.Register(controllerType);
            }

            // Register your types, for instance:
            container.Register<IRepository, Repository>();

            // register MVC controllers (This is an extension method from the integration package).
            container.RegisterMvcControllers(Assembly.GetExecutingAssembly());

            // register MVC attributes (This is an extension method from the integration package as well).
            container.RegisterMvcAttributeFilterProvider();

            // Verify the container configuration
            container.Verify();

            System.Web.Http.GlobalConfiguration.Configuration.DependencyResolver =
                new SimpleInjectorWebApiDependencyResolver(container);

            System.Web.Mvc.DependencyResolver.SetResolver(
                new SimpleInjector.Integration.Web.Mvc.SimpleInjectorDependencyResolver(container));

        }
    }

New Post: WebActivator Initialization vs. Global.asax app_start configuration paradigm

dot_NET_Junkie — Mon, 13 May 2013 18:21:13 GMT

An assembly is not the same as an NuGet package. In fact, the MVC Quick Start Package itself, does not contain an assembly. It contains a reference to three other NuGet packages (two Simple Injector packages and the WebActivator package) and one content file.

Again, none of the dlls (assemblies) provided by Simple Injector reference the WebActivator. To integrate Simple Injector with MVC you don't need the MVC Quick Start package. The Quick Start is really just built to bootstrap everything together. If you don't want to use WebActivator, just deinstall the MVC Quick Start package and use the SimpleInjector.Integration.Web.Mvc NuGet package directly. The assembly in that package depends on SimpleInjector.dll and SimpleInjector.Integration.Web.dll and those are located in the NuGet packages with the same name.

SimpleInjector.Integration.Web.dll however, does not have a dependency on WebActivator. It only takes (besides SimpleInjector.dll) a dependency Microsoft.Web.Infrastructure.dll, which is part of the .NET framework.

New Post: WebActivator Initialization vs. Global.asax app_start configuration paradigm

omegaluz — Mon, 13 May 2013 15:54:28 GMT

The statement "none of the Simple Injector assemblies in fact have a dependency on WebActivator" seems to be incorrect. I just tried to uninstall WebActivator after uninstalling the Quick Start NuGet package and get the following:

"Unable to uninstall 'WebActivator 1.4.4' because 'SimpleInjector.Integration.Web 2.2.3' depend(s) on it."

New Post: Scenario questions about SI

androticus — Sun, 12 May 2013 16:05:13 GMT

That was all very helpful, thanks!

New Post: Scenario questions about SI

dot_NET_Junkie — Sat, 11 May 2013 10:18:25 GMT

Simple Injector does not allow resolving Lifetime Scoped instances outside the context of a scope. This design is deliberate. One of the earlier versions of the framework in fact behaved differently and followed the design of Autofac and other containers to return a singleton instance in the case there was no scope.

This design however proved to be bad, since returning a singleton is almost always a bad idea, since components are often registered with Lifetime Scope because they are not thread-safe and should not be reused. A great example of this is the Unit of Work pattern that Entity Framework implements with its DbContext and ObjectContext classes. We saw users spinning off background threads and forget to start a new scope, which caused their Unit of Work class to be shared over multiple threads, which lead to errors in production.

Because of this we decided to disallow this by default. Perhaps your case is different and it is okay to return a default instance. If you really want to do this, you can enable this by using a Hybrid lifestyle, as follows:

var scopedLifestyleWithSingletonFallback = Lifestyle.CreateHybrid(
    () => container.GetCurrentLifetimeScope() != null,
    new LifetimeScopeLifestyle(),
    Lifestyle.Singleton); // the fallback lifestyle

But please take a look carefully at your design if this really is what you need and if it is possible for a programmer to make a mistake in such way that things accidentally are returned as singleton, while it should have been scoped. Since you are running a Windows Service that spins of new threads to do its work, it seems very unlikely that any code should even run outside the context of a lifetime scope.

When you spin of a background thread and have any components registered as Lifetime Scope, you will have to wrap the execution with a lifetime scope. You will have to start the scope before requesting the root object, for instance:

Task.Factory.StartNew(() =>
{
    using (container.BeginLifetimeScope())
    {
         // resolve root object
         var service = container.GetInstance<ISomeService>();
         service.Do();
    }
}

This code should be part of your application's Composition Root and not of any application code. This prevents the application to know anything about it. Of course the code cannot run without outside the context of a lifetime scope, but this is quite obvious. The fact that the consumer should now as little as possible doesn't mean it should be able to work in any case. Not starting a scope is a misconfiguration and you'd rather see the application fail than silently continue in error. Neither would you want the application to continue when one of your registrations is missing. You should always fail fast.

I want the middleware to use the logging object that is for that specific service.

This seems more like Context Based Injection.

Lifetime Scoping in Simple Injector differs from the concept of Child Containers that frameworks such as Unity use. A child container allows you to do special registrations in that child container. Simple Injector does use this approach, since it is impossible to both allow creating child containers with new registrations and having good performance at the same time. If I understand correctly you want to register a new instance at the beginning of the thread and reuse that same instance for the duration of that scope. There are several ways to do this. Here is an idea:

// Registration
container.RegisterLifetimeScope<LoggerContext>();

container.RegisterLifetimeScope<ILogger>(
    () => container.GetInstance<LoggerContext>().Logger ?? 
        NullLogger.Instance);

// This class is unknown to the application, only known in 
// the composition root.
public class LoggerContext
{
    public ILogger Logger { get; set; }
}

// Part of the Compostion root that starts a use case:
Task.Factory.StartNew(() =>
{
    using (container.BeginLifetimeScope())
    {
        // Set the logger to be used during this scope.
        container.GetInstance<LoggerContext>().Logger =
            new Logger(typeof(ISomeService), "special stuff");
    
         // resolve root object
         var service = container.GetInstance<ISomeService>();
         service.Do();
    }
}

New Post: Can Simple Injector support Web API and MVC Controllers simultaneously?

dot_NET_Junkie — Sat, 11 May 2013 09:35:43 GMT

What is exactly the problem you are having?

Although not advised, integrating MVC and Web API in the same project is possible. But since both frameworks have their own API for dependency resolution, you will have to make sure that you register both the MVC DependencyResolver and the Web API DependencyResolver, like this:

System.Web.Http.GlobalConfiguration.Configuration.DependencyResolver =
    new SimpleInjectorWebApiDependencyResolver(container);
        
System.Web.Mvc.DependencyResolver.SetResolver(
    new SimpleInjector.Integration.Web.Mvc.SimpleInjectorDependencyResolver(container));

New Post: Scenario questions about SI

androticus — Fri, 10 May 2013 21:34:45 GMT

Here is code for the Scoped Instance Scenario (I will provide the other scenario in another message). I think it is easiest with the concrete use- case, which is for a logging interface. We have a lot of code that is in windows services, where the code provides several different services running on different threads using different loggers. When I make a call to the middleware in a scoped instance from one of those threads, I want the middleware to use the logging object that is for that specific service. The example below is for some middleware service ISomeService that takes a ILogger which I want to supply. I want to set that instance of the Logger in the scope so that all DI resolutions within that scope will use that logger instance.

//ctor for SomeService : ISomeService

public SomeService(ILogger logger) {
...
}

// sample scenario:
Container container = new Container();

// global registrations not shown
container.Register<ISomeService, SomeService>(new LifestyleScoped());

using (container.BeginLifetimeScope())
{

container.RegisterSingle<ILogger>(anExistingLoggerInstance); // THIS IS WHAT I WANT TO DO

...

//
ISomeService svc = container.GetInstance<ISomeService >(); // SHOULD GET CONSTRUCTED WITH THE INSTANCE I SET

}

New Post: Can Simple Injector support Web API and MVC Controllers simultaneously?

Sergeir — Fri, 10 May 2013 20:32:56 GMT

I have an MVC 4 ASP.NET Web API project in which I want to be able to inject a repository into both a MVC controller and an Web API controller. Obviously the project itself supports both types of controllers. I have found documentation on the Simple Injector site which shows how to implement either but not both at once.

I have tried several methods, both of which can be seen in the code below, to no avail:

 public static class SimpleInjectorInitializer
    {
        /// <summary>Initialize the container and register it as MVC3 Dependency Resolver.</summary>
        public static void Initialize()
        {
            var container = new Container();

            // register Web API controllers (important!)
            var controllerTypes =
                from type in Assembly.GetExecutingAssembly().GetExportedTypes()
                where typeof(IHttpController).IsAssignableFrom(type) 
                where !type.IsAbstract
                where !type.IsGenericTypeDefinition
                where type.Name.EndsWith("Controller", StringComparison.Ordinal)
                select type;

            foreach (var controllerType in controllerTypes)
            {
                container.Register(controllerType);
            }

            // Register your types, for instance:
            container.Register<IRepository, Repository>();

            // register MVC controllers (This is an extension method from the integration package).
            container.RegisterMvcControllers(Assembly.GetExecutingAssembly());

            // register MVC controllers - second method (This is an extension method from the integration package).
            //var mvcControllerTypes =
            //    from type in SimpleInjectorMvcExtensions.GetControllerTypesToRegister(container, Assembly.GetExecutingAssembly())
            //    where type.Name != "HelpController"
            //    select type;

            //foreach (Type controllerType in mvcControllerTypes)
            //{
            //    container.Register(controllerType);
            //}

            // register MVC attributes (This is an extension method from the integration package as well).
            container.RegisterMvcAttributeFilterProvider();

            // Verify the container configuration
            container.Verify();

            // Register the dependency resolver.
            GlobalConfiguration.Configuration.DependencyResolver =
                new SimpleInjectorWebApiDependencyResolver(container);
        }
    }

Here is the SimpleInjectorWebApiDependencyResolver calss taken from the Web API guide:

public sealed class SimpleInjectorWebApiDependencyResolver
    : IDependencyResolver
{
    private readonly Container container;

    public SimpleInjectorWebApiDependencyResolver(
        Container container)
    {
        this.container = container;
    }

    [DebuggerStepThrough]
    public IDependencyScope BeginScope()
    {
        return this;
    }

    [DebuggerStepThrough]
    public object GetService(Type serviceType)
    {
        return ((IServiceProvider)this.container)
            .GetService(serviceType);
    }

    [DebuggerStepThrough]
    public IEnumerable<object> GetServices(Type serviceType)
    {
        return this.container.GetAllInstances(serviceType);
    }

    [DebuggerStepThrough]
    public void Dispose()
    {
    }
}

http://simpleinjector.codeplex.com/wikipage?title=Web%20API%20Integration
http://simpleinjector.codeplex.com/wikipage?title=MVC%20Integration

New Post: Scenario questions about SI

dot_NET_Junkie — Thu, 09 May 2013 19:44:33 GMT

I'm afraid I don't fully understand your question. Could you please supply me with some more details?

You cannot request an instance of a service that has been registered as scoped in a global context.

Are you talking about the Lifetime Scope lifestyle?
Do you mean that you can't get an instance when you didn't call container.BeginLifetimeScope()?

No apparent way to set a scoped instance

Can you supply me with a concrete (realistic) code example of what you're trying to achieve?

New Post: Scenario questions about SI

androticus — Thu, 09 May 2013 19:08:16 GMT

I have been evaluating Simple Injector, and am having challenges with the following scenarios. I was hoping for some comments:

Scoped registration and instancing are tightly coupled and code must be aware

You cannot request an instance of a service that has been registered as scoped in a global context. You can only register as scoped, and then need to retrieve as scoped. This seems to violate a principle that the consumer of the service should need to know as little as possible about details like this.

No apparent way to set a scoped instance

You can manually set instances of globally scoped services, but you can't seem to set instances of scoped services. Example scenarios:
Outer, global logging instance. Some scoped calls would like to supply a scoped logging object that applies to the calling context.
Outer, global security credentials object. Calls outside a scope want to use the global security credentials, but some scoped calls provide their own credentials, want to set those.

I realize you can probably do this stuff with various specialized Factory objects and/or instance caches etc., but that seems to defeat the purpose of having a DI framework. Thanks for any feedback!

New Post: WebActivator Initialization vs. Global.asax app_start configuration paradigm

dot_NET_Junkie — Thu, 09 May 2013 18:57:41 GMT

I must admit that I myself prefer the use of the Global.asax and Application_Start. I do use the Quick Start package, but copy the need configuration to the Global.asax and uninstall the package afterwards.

The use of the WebActivator however, was chosen because this allowed users to get started with Simple Injector just by pulling in the "Simple Injector MVC Integration Quick Start" NuGet package. That package just contains some references to other NuGet packages and one single content file. Adding a content file is a very safe. It prevents having to use tricky Visual Studio integration, which would be needed when an existing Application_Start was altered. Besides, the addition of one single content file is much easier to grasp for developers, compared to finding out that existing files and code has been altered by some package.

So we went for the safest way that is easiest to explain to developers. If this doesn't suit you (as it doesn't really suit myself either), I advice you to just do what I do: copy that code to the Application_Start and uninstall that package.

Note that that although the Quick Start NuGet package takes a dependency on WebActivator, none of the Simple Injector assemblies in fact have a dependency on WebActivator, so from an architectural perspective there's no problem here. And again, if you don't want to take a dependency on WebActivator, just uninstall the Quick Start NuGet package and you're fine.

New Post: WebActivator Initialization vs. Global.asax app_start configuration paradigm

omegaluz — Thu, 09 May 2013 18:04:18 GMT

Personally, I like the direction the MVC team has gone in recent years in regards to any application_start code. Take any of the following for examples:

protected void Application_Start(Object sender, EventArgs e)
    {

        ViewEngineConfig.Configure();

        AreaRegistration.RegisterAllAreas();

        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);

    }

Using WebActivator goes against this practice and also added another dependency to your project. Technically, your SimpleInjectorIntializer class can be re-written to use the above paradigm and then remove the need for WebActivator.

What do you think?

New Post: Simple Injector - Why and where does it loose points?

dot_NET_Junkie — Wed, 08 May 2013 10:46:58 GMT

Hi Rod,

Simplicity is one of the main goals of Simple Injector and Simple Injector tries to make it easier for developers to start with Dependency Injection. The feature set of Simple Injector is deliberately stripped and with that it tries to push developres in a certain direction that we feel is best; results in the most maintainable software. This doesn't mean that it is limited in its possibilities, but makes forces you to do a bit more work to get certain behavior. Take for instance making registrations with by name/key and doing implicit property injection. Both features are possible to implement in Simple Injector, but not supported out-of-the-box (OOTB), because they are abused most of the time and can lead to DI configurations that are hard to verify. We do however provide documentation that explains most scenarios that are not supported OOTB.

Many developers fear the performance of their DI container. In reality most of the time your container´s performance isn´t an issue, but on the other hand, it´s hard to intuitively sense where the performance bottlenecks are and how to solve them. That is something Simple Injector tries to solve. Everything you do OOTB is fast. About as fast as when wiring things by hand (except the constant overhead a call to GetInstance() has, and the one-time performance hit of the initialization phase). This allows developers to stop worrying about the container's performance.

Simple Injector however is is specially designed with a specific type of architecture in mind. Architectures that are based on the SOLID principles, work with generic abstractions, and use decorators to apply crosscutting concerns (take a look here, here, and here for examples of this type of design). Especially the area of using decorators is where other containers lack and where Simple Injector tries to fill a gap. Most containers use a method called interception to apply crosscutting concerns to types, and make it really hard to apply decorators in a way that is maintainable. In our opinion, the use of decorators is much better than using interception, because decorators don´t force you to take a dependency on some interception library, and results in code that is simpler and faster. Simple Injector for instance, makes it very easy to apply (generic) decorators conditionally, based on either a predicate or a generic type constraint.

Unity makes it possible to apply decorators, but when it comes to applying decorators conditionally, this gets really hard in Unity, and will lead to a DI configuration that becomes unmaintanable. Whether or not this is a problem, depends on the size and design of your application, of course.

Of course I´m biased about Simple Injector, and would argue that you can do anything with Simple Injector, but perhaps not OOTB. So things that are supported by Simple Injector OOTB but are in Unity are for instance keyed registration, interception, and handling types with multiple constructors. Simple Injector on the other hand is very fast and has very good support for decorators.

The choice is up to you.

New Post: Simple Injector - Why and where does it loose points?

RBoavida — Wed, 08 May 2013 08:33:56 GMT

Hi,

I must say I was very impressed with the performance benchmarks I've seen out there regarding Simple Injector as well as the documentation you are providing.

I'm looking into DI frameworks for my company's new product and came across SI.

There is already new developments using Unity for Web applications. The natural way would be to go with Unity. The new product is to be a cloud based multi-threaded application with multiple activations per second so completely different picture.

I have two questions that could help me a lot to decide and influence decisions.

1 - What motivated you on developing such a framework considering the existing ones out there? If it was performance I would like to know about that business case
2 - What are the concrete feature limitations on this framework? From what I'm seeing it can do almost everything as Unity.

Tnks in advance,
Rod

New Post: Registering open generic of open generic

timohayes — Fri, 03 May 2013 19:34:18 GMT

That did the trick, thanks. I have other reasons why I need the extra abstraction, but your point is well taken.

Thanks very much for Simple Injector, it is a really great tool!