Put IoC front and centre
Bake inversion of control into the framework and reduce the reliance on inheritance. This will allow greater extensibility and enable new scenarios. A good example of this is MVCTurbine (http://turbineproject.com) - rather than developers having to roll infrastructure themselves, they could hit the ground running with their IoC container of choice.
We are planning to provide a common service provider abstraction for web applications.
We are addressing this feature request in ASP.NET vNext (http://www.asp.net/vnext), which introduces a central abstraction for dependency injection. Out of the box we provide a simple IoC container to bootstrap the system, but you can easily replace it with your IoC container of choice. You can follow our progress on ASP.NET vNext at http://github.com/aspnet.
Scott McFadden commented
@Daniel Roth, Please consider adding IOC support for custom IHttpModule instances. Registering HttpModules via web.config is very limiting.
DynamicModuleHelper.DynamicModuleUtility.RegisterModule is a good first start but it is limited to module types and can not inject module instances. Even better would be if the user could specify a custom module factory for creating IHttpModule instances (similar to how MVC does it).
We have to jump through some serious back door / unsupported / brittle hoops to make http module constructor injection work in current ASP.NET 4.51.
AMIR HOSSEIN FATTAHI commented
Andy writes: "Adding solutions to a core framework because they are seen elsewhere usually tends to end up with the framework being quite messy over time."
That's exactly where we are today. The .NET framework is already messy. There's a plethora of ways to extend it. You can do Provider-like stuff with XML configuration, some places there's Provider-stuff you can do with code, but sometimes the code adding the providers need to run at a certain time in the bootstrap of the application so you have to add it through the PreApplicationStartAttribute, then you have the ServiceLocator-based in ASP.NET MVC and Web API. These are just some, from the top of my head.
Why can't all of these different IoC techniques be obsoleted in favor of one, central, common IoC container that doesn't need to be "front and centre", but that is used (transparently, if you don't want to bother with it) in every part of the .NET framework? Why are all these different ways of extending and replacing parts of the .NET framework required to be different?
Not sure I agree with this request. IoC is really an application architecture technique and can be achieved in a number of different ways. For example, in .Net framework 4 and higher there is MEF and MAF which work together to provide some of this functionality. A good developer can also implement their own version of IoC tailored more specifically for their application.
Adding solutions to a core framework because they are seen elsewhere usually tends to end up with the framework being quite messy over time. My preference is to just have a core of basic functionality that can be layered up or extended to provide the required functionality by the developer. It is only a 10 minute job to do this type of design using any visual design tools or even using the old traditional and reliable pencil and paper method.
It's incredible that so many people are unable to grasp the fact that IoC can be made even more invisible in the framework than the current chaotic Provider/Factory/Configuration "system". IoC is just a well defined way to extend the framework, which takes preference to using interfaces as a way to define contracts between interdependent parts.
Using IoC doesn't mean that everyone needs to find, learn and install an IoC container in every solution. It doesn't mean all components they want to use needs to be registered in the container. It doesn't mean that all the code they write needs to adhere to an IoC pattern. It just means that if people want to, it's possible.
Right now, it is absolutely impossible to do anything sensible with most parts of the .NET framework. There are just too many static classes that do "magical" stuff, bootstrapping the whole AppDomain without you being in control at all. The only way to extend anything is to inherit massive and bloated abstract base classes which gives you more than you want and doesn't allow you to override the functionality you do want.
Using IoC is more about having the .NET framework follow good coding practices and less about choosing an IoC container. It's about having one, clear way to extend and replace components of the framework, instead of the myriad of different ways we have today.
Many solutions do not fit the IoC pattern. Avoid putting this in the framework or as a preferred solution type.
Brett Baggott commented
I think something like Side Waffle should be more front and center and IoC should be in templating. IOW, the focus should be on lots of _really_ good templates.
Jonathan McPhail commented
I agree with Seemann, this is already so incredibly easy to do, it offers little to no benefit and will only confuse new users that aren't familiar with ioc. Furthermore, how this is done could impose unwanted restrictions on certain other IOC frameworks that don't come "baked in."
Peter Porfy commented
Asbjørn: DI containers use System.Activator to create objects so it would be interesting if System.Activator would use a DI container to create objects.
I understand what you are saying but I don't think a DI container would be a great choice for core parts of the framework because you can't define a composition root on that level. It may use it as a universal factory (service locator) but I think that is harmful. Maybe some parts of the framework can be improved for easier dependency injection but a DI container is not relevant for this.
Microsoft.Practices.ServiceLocation.ServiceLocator was neved being updated, is bogus and badly designed (e.g. Current throwing an exception, this is terrible) thus it ultimately sucks and shouldn't be used by anybody until fix.
Peter, Mark; it's not hard at all. Microsoft just needs to provide a default container implementation that plugs into the existing Microsoft.Practices.ServiceLocation.ServiceLocator (which needs to be pulled into the core library) and then use the ServiceLocator to construct objects. Alternatively, System.Activator can be extended to support IoC containers.
This is not about making the core framework harder to use. The default instances of all objects should be like they are now, so if you don't want to use an IoC container, you shouldn't need to worry about its existence at all. But if you want to replace a core object with your own implementation, plugging it into an IoC container should be easy and supported by the framework. Today it's not easy, not supported by the framework, and implemented in several different ways via web.config (MembershipProvider, RoleProvider, etc), code registration (ControllerFactory), etc.
Doing this with IoC just provides consistency across the entire framework, eases testing and makes replacing core objects with custom implementations intuitive. Sure, there's security issues involved here, and I'm not saying absolutely all objects should be replaceable in all circumstances, but those that already are, should at least do it in a consistent way.
Peter Porfy commented
How would you bake Inversion of Control into the framework? It makes no sense. Or you would like to see the framework to use a DI container for ad-hoc object creation? That would be a nightmare.
Mark Seemann commented
What would that do? Where should it apply?
MVC and Web API already have 'good enough' extensibility points to allow you to hook in your DI Container of choice.
DependencyResolver (or whatever name it may go under) is a dead end. The framework needs less of such half-baked solutions, not more.
Web Forms doesn't have DI support, but I think it's better to just let it die than attempt to resurrect it with misunderstood 'DI support'.
Jonathan Allen commented
Where is the down-vote button?
IoC should NEVER be front and center. It should be tucked away in a corner so that the bulk of the application doesn't even know you are using it.
It does NOT need a MEF job.
Jeffrey Palermo commented
This sounds good on its face, but I don't think IoC is the solution. The principles behind IoC are the solution. Composition over inheritence and fulfilling dependencies at runtime are two of the most important design principles.
definitely needs a MEF job.