Since I thought my problem was solved I went on to working on other parts of the ASP.NET MVC side of Project Thor. However, one day, like yesterday, I was running the app and wanted to adjust an admin setting on the Silverlight side, so I typed in the url to the Silverlight page, and I got another 404. What?! That wasn’t supposed to happen. Grrr!

I started going down some pretty nasty rabbit holes on this one. I knew it had something to do with routing, but being new to ASP.NET MVC I wasn’t sure what exactly it could be. At one point I had myself convinced it had do something with local Azure development fabric and integrated pipeline mode on IIS 7.0 running on Windows 7. I wasn’t getting anywhere. I’m not the type of guy that posts my problems and asks for help. I like working through these things on my own (yes, I am a glutton for punishment). However, I needed to get moving so I put the question on Stack Overflow. Within minutes, like 1 minute, I had two responses. The first response was on twitter from John Sheehan. The other response was on Stack Overflow and from none other than Phil Haack. Both responses weren’t a direct answer to my question, but they both pointed me to the ASP.NET Routing Debugger. As the page says:

“This utility displays the route data pulled from the request of the current request in the address bar. So you can type in various URLs in the address bar to see which route matches. At the bottom, it shows a list of all defined routes in your application. This allows you to see which of your routes would match the current URL.”

I downloaded the utility and fired the app up. Here’s what I got for the default page:

Good. Exactly what I expected.

I then tried to navigate to the configuration page that contains the Silverlight application:

Bam! There’s the error! I shouldn’t be getting a match on the first route, the route I want MVC to ignore, the route I told MVC to ignore in my last post. D’oh! If you remember, my RegisterRoutes method looked something like this:

public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{Services}/{*pathInfo}");
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

            routes.MapRoute(
                "Configuration",
                "Configuration",
                new { controller = "Configuration", action = "Index" }
            );

            routes.MapRoute(
                "Calendars",
                "Calendars/{id}",
                new { controller = "Calendar", action = "Index", id = "" }
            );

            routes.MapRoute(
                "Default",
                "{controller}/{action}/{id}",
                new { controller = "Account", action = "Index", id = "" }
            );
        }

See those curly braces around Services in the first line of the method. Those curly braces that are the MVC convention for replacement. Yeah, um, those shouldn’t be there. I’m not replacing anything. I want to ignore any calls to the actual Services directory. So the updated line looks like this:

routes.IgnoreRoute("Services/{*pathInfo}");

Once I made this change here’s what the testing utility showed me.

Perfect! When I then ran the app without the route debugging utility in place it worked as expected. I’m always amazed and at how so many seemingly complicated problems are solved with one line of code.

So, what’s the upshot of all this? Well, as I mentioned previously, the main goal of Project Thor is to help people, especially me, learn about other technologies they don’t get to work with on a day-in/day-out basis. Today I learned two things about ASP.NET MVC:

1. Routing is incredibly simple, ONCE YOU UNDERSTAND IT!!!
2. There is a great ASP.NET MVC community out there willing to offer assistance if you need. (Thanks again John Sheehan and Phil Haack!)

In my opinion Project Thor is, once again, accomplishing its goal. Now to finish version one!

In my last post I wrote about how I’m going to spending some time focusing on UX. However, I will be spending some time on other endeavors as well. One of those endeavors is Project Thor. I don’t want to go into all the details of Thor as I’ll be posting more about the project as we get closer to our February 1st release date. However, I ran into an issue last night/this morning that I thought deserved an immediate post. One of the goals of Thor is to get developers exposed to technologies that they might not otherwise have a chance to tinker with. To that end we’re using things like Windows Azure, Microsoft Tag, Exchange Web Services, Powershell, Silverlight, WCF RIA Services, and ASP.NET MVC. We’re using Silverlight and WCF RIA Services to provide a configuration front-end to the app. ASP.NET MVC is being used to provide a mobile front-end that users will use to reserve conference rooms. I’ve been doing the Silverlight/WCF RIA Services and up until yesterday evening everything was working great. Data was flowing from the Silverlight app through the services to our Windows Azure storage mechanisms. Then, last night, one of the other developers told him he had checked in some changes to complete the MVC-ing of our Windows Azure Web Role and that his code (mobile web type stuff) was working. “Great!” was my initial thought. Then I pulled down the latest source code from CodePlex and realized that while his stuff was in fact working all of our Silverlight/WCF RIA Services was busted. WTF? Why would ASP.NET MVC code break our Silverlight/WCF RIA Services. Time to put on the debugger had and figure this sucker out.

The error I was receving was fairly non-descript but it basically told me the request resource (service) could not be found. The first thing I did was to take a look at what he had checked in, specifically in the web.config file. One of the more interesting entries I found was this one:

Now keep in mind I’m fairly new to ASP.NET MVC. I understand how it works at a high-level and I’ve built a couple of basic CRUD apps, but I haven’t really dived into the guts of it as I spend most of my time in Silverlight. Putting the web.config entry together with the error got me thinking that maybe this UrlRoutingModule thingy was intercepting the WCF RIA Service request coming from the Silverlight app transforming it into something that could no longer be mapped to the desired service. It took a while for me to put this together and Fiddler played a big role in helping me sort through this.

After doing a bunch of reading on MSDN to better understand both ASP.NET MVC and the UrlRoutingModule thingy I realized the key to solving this problem was the RouteCollection. I need to modify this to not route incoming requests for our WCF RIA Services. Doing this was pretty simple. The developer who MVC’d the app had checked a global.asax file. I found the following method in the class:

public static void RegisterRoutes(RouteCollection routes)
{
     routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
     routes.MapRoute("Default", "{controller}/{action}/{id}", new { controller = "Configuration", action = "Index", id = "" });
}

All I needed to do was add a route to ignore service calls. In my case, I keep all of the WCF RIA Services in a folder named Services, so I just wanted to ignore all calls to the Services folder. Here’s what I came up with:

public static void RegisterRoutes(RouteCollection routes)
{
     routes.IgnoreRoute("{Services}/{*pathInfo}");
     routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
     routes.MapRoute("Default", "{controller}/{action}/{id}", new { controller = "Configuration", action = "Index", id = "" });
}

F5 and voila! Problem solved! I know for a lot of you ASP.NET MVC veterans the answer to this problem was probably obvious. However as an ASP.NET MVC rookie I had to start digging into the guts of how ASP.NET MVC worked to solve this problem, which means I learned a whole lot about ASP.NET MVC, which is one of the main goals of Thor. So, in my mind at least, Thor is definitely on the right track.