The existing decorator implementation in Autofac requires decorator chains be declared in an explicit manner using named/keyed registrations. This was an intentional design decision to ensure that the correct decorators are applied in the correct order, even in the presence of dynamic registrations or those added in a late-bound manner. For better or for worse, it has become more common place in DI container implementations to imply meaning from the order that registrations are configured, and use that implication to change the behaviour of services resolved at runtime.
The dependency injection support in Service Fabric allows you to provide instances for reliable actors, stateful services, and stateless services. Instead of providing a conforming container abstraction the Service Fabric team opted to use a factory based mechanism instead. Factory methods for creating service instances are registered with the runtime via the
As Travis mentioned in his earlier blog post the road to 4.0.0 has certainly been an interesting one. This is largely in part because we got on the .NET Core train back in the early DNX days, and as a result experienced all the renames and breaking changes that come with using early bits of a new technology. It certainly highlighted to me just how much I had been taking for granted to the excellent tooling support that Visual Studio provides. There were a few points in time when the Visual Studio tooling would align with a public beta or RC version of .NET Core, but that wasn't useful to us because we had already moved on to working with the next release which was no longer compatible with that tooling. The tooling team was always playing catch up with what had already been finished and fixing things that had been broken. On the plus side I ended becoming more familiar with the new .NET Core command line tools and Visual Studio Code which is a great code editor that you can definitely be productive in.