Thanks Stephen - I'd missed the Compose method. Added that in to my startup class, registered the services and everything is working fine.

Knew it wouldn't be anything major.

This change means (correct me if I'm wrong) that any backoffice extension must use LightInject for DI?

It'd be really awesome to have a write-up on how to register services and implementations for plugins/content apps/whole sites, so we can start injecting stuff into both RenderMvcControllers and ApiControllers. Any chance you have something that could give us a head start?

FWIW, here's my current implementation:

public class UmbracoStartup : UmbracoComponentBase, IUmbracoUserComponent
{
    public override void Compose(Composition composition)
    {
        composition.Container.RegisterSingleton<ISomethingService, SomethingService>();

        composition.Container.Register<ISomethingPlugin, SomethingPlugin>();
    }

    public void Initialize()
    {
        // here we can register listeners etc, or do any other startup tasks
        ServerVariablesParser.Parsing += ServerVariablesParser_Parsing;
    }
}

Once those services are registered in Compose, they can be injected into controllers

public class MyController() : RenderMvcController {
    private readonly ISomethingService _somethingService;

    public MyController() : this(new SomethingService()) {}

    public MyController(ISomethingService somethingService) {
        _somethingService = somethingService;
    }
}

At least, that's my understanding.

It's the only way I could get it working, but I agree, it kinda defeats the purpose...

Tried it again just now without the default constructor, but LightInject complains about not having a parameterless public constructor. Highly likely it's user error on my part.

Thanks for getting back.

I don't think it's a user error on your part... you're seeing the same as I was when I played around with it.

Based on the previous comments I did manage to find the UmbracoComponentBase and the container registration stuff in its Compose method. But registering a service implementation didn't really work for my RenderMvcController - I got the exact same exception.

I also tried registering my service in a custom UmbracoApplication (I'm setting up a site so I have that luxury) but the same happens. I have yet to test if the registration works in an API controller.

It should (I believe) work in an ApiController - Umbraco's services are exposed on ServiceContext, ideally any other registered services would be there too.

Will try to find time today to fiddle more.

Thanks Nathan, works like a charm now!

You don't want property injection. That introduces temporal coupling which is a Bad Thing ™

So how do I get out of this dilly of a pickle in which I am mired?

Just to clarify.

You want to inherit from a base class and not have to specify the injected parameter?

Personally, that's a no-no for me. Without constructor parameters you have no idea when each injected service in the base class is available in the lifetime of your derived objects. That can lead to hard to track bugs.

Do you need inheritance? Why are parameters a big deal. The derived classes need to know about the parent since that's how inheritance works.

I want the base class to provide data from the service, and have it available to the derived class, without the ctor injection

public class Foo : IFoo {
    public IService Service { get; set; }

    public int Digits => Service.GetDigits();
}

public class Bar : Foo {
    public Bar() {
        var x = Digits + 1;
    }
}

If I have 20 different implementations of Foo, they shouldn't each need a reference to Service just to retrieve Digits.

If there's a better way to achieve this, I'm all for it.

In this case I recommend redesigning your classes to accept the service as a method parameter.

public class Foo {   
    public int Digits => Service.GetDigits(IService service);
}

public class Bar : Foo {   
}


public class Caller 
{    
     private readonly IService service;

     public Caller(IService service) {
         this.service = service;
     }

     public int GetDigits() {
         Bar bar  = new Bar();
         return bar.Digits(this.Service) + 1;
     }     
}

Ah well, guess what? That was my original design and it got changed by... popular demand. Not that you are not popular ;-) So yea... I'm not sure, don't know if there is a "right" answer to that one.

As for the rest of the thread... I'm following it and plan to post a reply.

Should have stuck with your guns there chum, you definitely had it right first time. :)

Relying on an external caller to invoke an initialise call is more temporal coupling.

UmbracoComponentBase never made it to 8.0.0 indeed. The more recent comments on this post do things differently. You may also want to read this post for more details.

Feel free to have a poke around in github.com/nathanwoulfe/plumber8

The .Web and .Core projects both use the composer pattern, but only .Core uses both composer and component.