MvcContrib working on Portable Areas

This is a pretty short post, and it is just enough to announce some plans on the MvcContrib roadmap.

Portable Areas

What is a portable area?  As you know, ASP MVC 2 is going to ship with an implementation of areas where an area can either be in in a single project or separate projects.  MvcContrib already has an Embedded View ViewEngine, which lets views be embedded as resources in an assembly.  The next step is to take an MVC2 area, wire in the embedded view engine, and compile it to a single assembly.  Then, you can publish your area as an assembly to distribute any number of controllers and views.  This can be used to distribute multiple pages that all work together.

I expect control vendors to use portable areas to make their rich control suites work with ASP MVC.  After all, when registering the portable area at application start, the routes are essentially being registered.  Even if there are no top-level pages in the area, it would be really easy for a control vendor to supply an area allowing the developer to type:


The area has multiple controllers and views, and they can be wired into an application in many ways.

Call for participation

If you are interested in participating in the development of Portable Areas within MvcContrib, please join the discuss list and create a GitHub fork of MvcContrib.


MVC Best Practices Posted on 10.28.2009 at 7:45 AM

Simone has a great post (as usual) on 12 ASP.NET MVC Best Practices : Controller: 1 - Delete the AccountController


Johannes Hansen said on 10.06.2009 at 3:31 PM

Hi Jeffrey, portable areas sounds like an awesome feature. I can't wait to try it out.

Also, could you please elaborate a little on the Embedded View ViewEngine you mention. I can't find in the documentation or the source for that matter.

Marcel said on 10.07.2009 at 3:58 AM

Hi Jeffrey,

we have accomplished a similar concept using MEF (Microsoft Extensibility Framework) and using a VirtualPathProvider in our custom ViewEngine. This allowed our "Modules", or as you call them "Portables", to be compiled in a separate assembly (with our views and usercontrols as embedded resources). We then created a MEFBootstrapper that would discover all our "Modules" and we would simply let the module "install" it's own Routes and resource paths on discovery.