Simplify service registration and use MSDI abstractions throughout.

I don’t know how to phrase this better but drop the tight coupling with LightInject like a hot stone for the .NET Core implementation.

This was discussed at great length pre V8.

https://issues.umbraco.org/issue/U4-11427

There was even an attempted PR. Unfortunately V8 was launched before it could be completed. In my opinion it also did not go far enough to simplify registration of services.

https://github.com/umbraco/Umbraco-CMS/pull/3955

The current DI implementation hurts extensibility through it’s complexity. Package development for V8 still undeniably suffers for a lack of ecosystem. There were slack channels created by package developers specifically to discuss navigating this complexity.

Using a custom LightInjectContainer is never a good idea; neither is running multiple containers.

CC/ @lars-erik

P.S I’m absolutely putting my hand up here to help design a more simplified approach.

[Shazwazza]

Merged 🎉 🚀 bloody amazing work everyone 😍 and yep I agree I think we should close this issue now and discuss further on #9397 & #9446 + created issues re: UmbracoBuilder enhancements and collection builders

[p-m-j]

I have the site working for install & run (backoffice good post install) with CoreRuntimeBootstrapper removed.

The tests aren’t very happy but this is huge.

RuntimeState.Level determined as part of Startup.Configure instead of Startup.ConfigureServices.

We can drop this BS

public static IUmbracoBuilder AddUmbracoCore(...
  Func<GlobalSettings, ConnectionStrings, IUmbracoVersion, IIOHelper, ILoggerFactory, IProfiler, IHostingEnvironment, IBackOfficeInfo, ITypeFinder, AppCaches, IDbProviderFactoryCreator, CoreRuntimeBootstrapper> getRuntimeBootstrapper)

We never have to call BuildServiceProvider, not even once! (if we fix a couple more little bits)

---

And tests passing, there’s still more cleanup to do but this is so much better 8b97ce6 (and my wife will kill me if I don’t step away from PC)