Background
We're redesigning an internal web application (ASP.NET MVC3), with the goal of easing development and especially deployment. The application is a back office web, to which several teams develop modules. The last few years, this has been done working in the same project, and then doing a full release of "everything" whenever anyone needed to release. Unsurprisingly, this hasn't worked that well. We are now in a situation where half a dozen teams want to release modules, on different schedules, which makes the situation unbearable.
What we would like to accomplish:
- Each team develops their own separate modules, which are then loaded into the framework.
- Such modules should be deployable without redeploying the base application, or any other modules.
- Modules need to be able to provide partial views to other modules
The problem
We have made a proof-of-concept fulfilling all three requirements. Intermodule communication is handled using DI containers. This works quite well - with one caveat. When modules have different versions of some dependency, we get a version mismatch. If we want to avoid going back what we have and forcing everyone to re-deploy every time someone updates some dependency, we need to be able to load several versions of dependencies.
From what I understand, this will require us to load modules into separate AppDomains. This seems to raise a number of issues. Firstly, a number of discussions seem to say that this works very poorly with IIS/ASP.NET with regards to ThreadStatic variables etc. Secondly, we will need to do marshalling between the domains, which seems non-trivial and will add a lot of complexity. Thirdly, intermodule communication also looks to become painful.
I've looked briefly at MAF, which at least seems to give some framework support for this type of architecture, but it also looks decidedly complicated... Are there better alternatives, either some supporting framework, or design?