Art Of Programming

musings by Dmytrii Nagirniak

ASP.NET MVC Most Annoying Issues

  • No support for SSL in routing  (no URL generation configured in a single place). One big hack is here.
  • No support for (non)SSL redirect using RedirectToRoute (so it is not possible to redirect to (non)SSL page from controller action, except generating absolute link manually).
  • HttpExeption is handled as any other one except if its Code is 404. Inconsistent. But is “as designed” in ASP.NET generally (FTW again).
  • It reuses interface of the HttpContext class just acting as a proxy (HttpContextBase). Thus it inherits all the issues it has. It had to be different interface that abstracts from HttpContext (in particular the ApplicationPath’s trailing slash issue).
  • No support for Fragment part of URL in routing.
  • Weird ValueProvider – sometimes its value is array, sometimes string. The behaviour is consistent, but not naturally understandable. Have to wrap all that stuff with my own utility to unwrap that.
  • NullReferenceException occurs accessing routes if not properly used.
  • Annoying RenderPartial with model. Has to create a new ViewDataDictionary.
  • Empty values are used instead of NULLs. By default if user leaves a field blank (non-mandatory) empty string is bound to the property. It will be fixed in MVC2.
  • In reality, rarely you can use the typed C# 3.5 syntax for routing MvcContrib fixes that and I did it.
  • The default data binding is NOT secure and it is often encouraged. This also applies to Castle MonoRail. To protect it we need to specify white-list (which leads to another problem) or use ViewModel/DTO (which I do) and thus write more code.
  • The white-list of databinding properties is array of STRINGS. No type sefety. I write my wrapper to convert Expression<Func> to string. Fixing and patching again.
And this is the list I only remember now…
Generally the idea behind ASP.NET MVC is great. Even one of my ideas had been implemented in it.
But the delivered implementation has to be patched and wrapped with your own utils. Only after that it can be used consistently.
I am using ASP.NET MVC for about half a year or so and I still do prefer it instead of WebForms. Probably I just had to choose Castle MonoRail. I have never used it, only looked around, read blogs and looked into code samples, but it seems to be a bit more mature. It probably has less “features” (one is worth noting - routing), but I believe it at least performs consistently everywhere.
I am just so tired of patching, wrapping, extending, fixing all the Microsoft things…
I probably just need to go to holidays for a while to cool down a bit.
I should also mention the most positive tools I used with ASP.NET MVC:
I do encourage you to contribute to NHAMl in any possible way. That is a real thing.

Ohh. And I have a great idea. Let’s rewrite all the tools we find design issues in? Huh?
Are you brave enough to tell that?
…hmm… I am probably not.
Though I want to.


ds r4
that SSL certification problem is such annoying. It gets problemetic even if you change the browser.
Dmytrii Nagirniak
Upps. Sorry. I really thought fragment IS sent to server as part of the URL.

Well, then there is really no way we can get the fragment on the server. But it should still be possible to generate the fragment so it can be used on the client.
That's not the case at all. Try the following experiment. Open up Fiddler2. In your browser, type in any URL with a URL fragment. For example, I chose

Fiddler shows the following request being made:

GET /default.aspx HTTP/1.1

Notice that #foo is not included as part of the request.

Check out the Wikipedia entry on "Fragment identifier" which states:

"The fragment identifier functions differently than the rest of the URI: namely, its processing is exclusively client-side with no participation from the server."
Dmytrii Nagirniak
Hello Phil,

For the Fragment, it is part of the URL and is sent to the server and thus can be used. Not too sure what you mean.

Ideally the the fragment part shuold be defined as part of the route:

So the '#' should be taken into account when it is absent when matching/generating routes. So that all of the follwoing URL will match the route:
Thanks for the feedback. Regarding the Fragment part in URL Routing, how could we support that? The URL fragment is *not sent to the server*.

The fragment is interpreted by the browser and is not sent over HTTP to the server.