We were converting the CodePlex application over to ASP.NET MVC Preview 3 today and found a nasty bug with RedirectToAction. In reality, the bug isn't so much around RedirectToAction, but a change they made internally to Routing. However, this seems to only happen in certain routing scenarios. Take the following routes:
1: routes.MapRoute("Login", "site/home/{action}",
2: new { controller = "session", action = "login" });
3: routes.MapRoute("User Info", "site/user/{action}",
4: new { controller = "user", action = "show" });
The problem crops up within your UserController actions when attempting to redirect to other UserController actions. For instance
1: public class UserController : Controller {
2: public ActionResult Show() { ... }
3: public ActionResult Create() {
4: return RedirectToAction("Show");
5: }
6: }
when line 4 is executed above, it attempts to redirect you to "~/site/home/foo". The reason is the change that was made is now trying to remove all the ambiguities by "assuming" things on the fly. Since the actionName overload of RedirectToAction doesn't take and doesn't supply the controller it cannot find the appropriate route. After a bit of convincing, the bug has been acknowledge but I make no guarantees if and when it'll be fixed in a future build - but in the mean time, you're stuck with
- Fixing the code yourself from the CodePlex source drop. This simply involves supplying the current executing controller's name in the route value dictionary.
- Use the RedirectToAction overload that takes both actionName and controllerName.
- Use my lambda expression based RedirectToAction which correctly sends both actionName and controllerName.
And, before anyone asks - why are you creating such complicated routing? Well, simple - simple routing equals a very simple application. Complex routing equals a pre-existing and well defined "RESTful based" urls that mean something when a user reads it.
cf38da96-eba1-4a55-91e8-fff47159ed4f|0|.0