Enterprise Library 6 Released; Target Framework Question

[Travis Illig]

Microsoft P&P just released Enterprise Library 6, which has some breaking changes in it. One of the big things they've done is target .NET 4.5 specifically.

Autofac has had a history of being compatible with the latest releases of things - MVC, SignalR, etc. It would make sense that we update the Autofac.Extras.EnterpriseLibraryConfigurator to reference the new version of EntLib.

The question arises when we look at the target framework, though. Everything in Autofac right now targets .NET 4.0. If we update to use EntLib6, chances are that Extras library will need to switch to target .NET 4.5.

Any issues with switching just the one library to .NET 4.5? I can see we'd need to update the NuGet package structure for it, etc. Anything that might cause problems, though?

[Alex Meyer-Gleaves]

I can't think of any problem. Changing that one Extras package shouldn't have an impact on anything else.

[Travis Illig]

OK. There's a non-trivial amount of day job time right now so I'll get on that ASAP, but most likely looking like next week earliest. I'm not sure there's a ton of clamoring for it anyway, but it'll be nice to get updated.

Since it's a move to a new platform (.NET 4.5 rather than 4.0) and there are some breaking changes in EntLib that mean it's not really backwards compatible... I believe that means an increment to the major number in the semantic package version for Autofac.Extras.EnterpriseLibraryConfigurator. It'll be the first of the releases where one of the libraries breaks with the 3.x versioning seen with the rest of the Autofac libraries and goes to a 4.x version, even though it's compatible with the 3.x set of core components. I hope that won't be too confusing for folks. Given the package version rev, I'll probably also end up switching the assembly/file version to match. 

[Travis Illig]

After doing some research, I don't think we can do anything for Enterprise Library 6.

In EntLib 5, there was a central "EnterpriseLibraryContainer" that was used for service location and central configuration parsing. All configuration was fairly implicitly tied to their type registration/IoC mechanism. You'd read configuration, it would parse into IoC registrations, and you'd push those into your container for later use. Lots of service location, etc. going on.

In EntLib 6, they've decoupled all of that. XML configuration no longer ties to IoC at all. Each application block knows about its own configuration (and no other block's); configuration elements internally know how to create the corresponding types. However, they've introduced an alternative mechanism for configuration - programmatic configuration. That's where you'd hook your IoC in.

Using Exception Handling Block as an example...

In EntLib 5 I'd run everything through this "magic" EnterpriseLibraryConfigurator that "knows" how to parse Unity type registrations into Autofac type registrations and when I call "container.Resolve<ExceptionManager>()" then everything would come together. There was no other way to really configure things.

In EntLib 6, it's much more "straight Autofac" as it were. Like, register your policies, register the ExceptionManager type, and call it good.
builder.RegisterType<MyPolicy1>().As<IExceptionPolicyDefintion>();
builder.RegisterType<MyPolicy2>().As<IExceptionPolicyDefinition>();
builder.Registertype<ExceptionManager>();

(It's a tiny bit more complicated than that, but you get the idea.)

EntLib 6 does offer a "fluent configuration building" grammar, but what that builds... is System.Configuration.ConfigurationSection objects - the same stuff that gets parsed out of XML.

So the choice for EntLib 6 users is:

• Use XML configuration.
• Use programmatic configuration (building up objects like exception handling policies manually).
• Use programmatic configuration (the fluent grammar that builds, basically, in-memory XML configuration).
• Use the IoC container directly instead of configuration.

What that means for our EnterpriseLibraryConfigurator is... I don't think EntLib 6 has an analog. I don't think we have any work to do.

If we do something, it'd have to be, basically, adapters on a per-block basis (one for Logging Block, one for Validation Block, etc.) that know how to read the respective block's configuration and register things in Autofac accordingly. I'm not sure if that's worth it or even valuable.

I'm thinking we should leave the EntLib 5 bits in there as-is and... that'd be the end of it. Anyone see it differently? Am I missing something?