Don’t even try using MVC2 on CMS6
...yet. Unfortunately it’s not possible to use ASP.NET MVC 2 on CMS6 (without running into a lot of trouble). The reason is that parts of EPiServer uses MVC1 and there are breaking changes between MVC1 and MVC2 preventing a simple assembly redirect.
The offending changes
The particlar changes that cause problems in this case are these:
- Http GET and return Json needs to be explicitly allowed in code return Json(…, JsonRequestBehavior.AllowGet);
- Change of return type to MvcHtmlString on html helpers
- Async controllers feature introduces a new way of calling the controller factory
Future upgrades of ASP.MVC
Now, if you’re using MVC1 please be aware that we’re planning to update ASP.NET MVC to version 2 and that you might be affected by changes above, or any of the other changes described in the ASP.NET MVC 2 RTM release notes
I’ve heard several requests to use MVC the second. If you feel this upgrade might be a problem don’t hesitate to add your comment below.
Sep 08, 2010
We're using MVC2 and would REALLY like to see support
Kind regards
We will try to use MVC2 disregarding your strong recommendation to do otherwise, the reason is that we will use a AJAX framework that will need to communicate with episerver through JSON and we will rather use the MVC2 framework for doing this rather than to depend on a third party library for that.
Will Episerver 6 R2 have support for MVC2?
We would love to take part of any progress that you have made so far in solving the issues you describe and others that we already have noticed when trying to combine the two versions.
I’m afraid the only way to get a fully functional CMS 6.0 site using MVC 2.0 is to use a custom MVC 2.0 build (or better yet, a 3.0 build). As Cristian mentions, there are three breaking changes.
Number one (GET/JSON result) and three (async controller support) can be worked around pretty easily using a dynamic proxy, wrapping and correcting the offending implementations. Number two, however, is a binary incompatibility that you really can’t work around, unless you’re prepared to hack some assemblies and register them for signature verification skipping (not a very comfortable solution, IMHO).
My team is successfully using a custom build, and everything is working just fine. The only drawback is having to rebuild 3rd-party assemblies that have a dependency on MVC (for instance Autofac). So far it hasn’t been a big obstacle, especially since we avoid closed-source dependencies as much as possible. YMMV, of course.
@Cristian Libardo: I’d be really happy if you would go the extra mile to break the hard dependency on a specific MVC version (and hey, maybe that awful old thing called log4net – NLog FTW!). There are several ways to achieve it, and you’ll end up with a less rigid framework. A win for everyone!
@Christian: Yes!
@Carl-Johan: That's one clever solution. I think MVC is stabilizing and don't expect any breaking changes in MVC vNext. Can you elaborate what you mean about removing dependency on the MVC version?