So I'm trying to set my routes declaratively in config rather than in code, and I've run into a few issues that spawned suggesstions:

Allow Route's Defaults to be set via name/value pairs: a Dictionary or any list of name/value pairs would be great.

Let's say I don't want to subclass route (more on that below) - that means when I construct a new Route object I have to use reflection.emit to create a type with properties named like the keys in the route defaults, then create an instance of that type, then set it's properties, then pass that in...

Since I started with name/value pairs and Route just turns those into a ParsedRoute with name/value pairs (by again using reflection) it seems like a lot of work to run in circles.

Make it easier to use our own Routes if Route class won't be extensible:  I'd like to be able to subclass Route and do what I need to do, but the methods called by RouteCollection are internal, and the supporting ones are private, so I can't do it easily at all.    Route doesn't take any services or anything to do its work, so I can't help it compose what I want. 

 
Thanks much for reading! 

 There is a codeplex RouteBuilder project that does this already.  Get around the anonymous type by building a typedescriptor and propertycollection.  The project has code which does this.

Also, Microsoft has already said they will be suppling overloads that take regular dictionaries or namevaluecollection instead of only anonymous objects or statically typed objects. 

For more on routing, check my blog, I should have an interesting post up about getting wicked cool functionality out of routing.  I am hoping to get it up this week, but it might not be until after the holiday. 

Thanks for the tip - I did see the RouteBuilder, but the amount of code needed to do it was.... a lot.

 I'm glad the MVC team has already stated they'd provide this overload - I must have missed it.   Good to hear.  

With all my customization to the routehandler, routing and controller I sometimes feel like I'm replacing or rewriting 75% of the routing bits - and I'd rather not do that.   I just depend so heavily on a DI container that the bits out there now just don't quite reach.   It's nice that they get me partway there, though!

 If that was useful... I'll take the points.

Second, what are you doing that is so complicated? 

I have found the default stuff to be very customizable, it feels a little hackish but the routing is very powerful for version 1 ctp. 

Lastly, why write routes in xml... I would rather slit my throat.  Why not just write code to auto register routes based on conventions, like namespace or some attribute or something.
 

abombss:

Second, what are you doing that is so complicated? 

Pushing the limits for fun and profit, of course! 

abombss:

I have found the default stuff to be very customizable, it feels a little hackish but the routing is very powerful for version 1 ctp. 

It is great for a CTP, no doubt.  I just want to make sure v2 CTP has my feedback.   I don't like having to re-write stuff that was marked internal, so I want to call out places where I needed to do so.  I agree with some of the hackishness, but it's great that it is possible to hack it - rather than hitting lots of brick walls.

The biggest issue I have is that I have to customize more than what I'd think I'd need to.  For example, in one of my early attempts I had to create a custom route handler in order to call my subclass of MvcHandler which was overriding GetType (which means I had to implement my own type cache) to call my DI container for the type by string so that later my ControllerFactory could get the same type out  of the DI container later.  All of this, when what I really needed was for the controller factory to have the RouteData passed to it rather than a Type.  Or for the MvcHandler to take a type resolution service.    They've already stated they'd probably change this a tad, which is great, but I want to make sure and call out all the places where this happens (like Route and Defaults) so that they are aware a person ran into it outside campus (even if I'm only a few blocks away).
 

abombss:

Lastly, why write routes in xml... I would rather slit my throat.  Why not just write code to auto register routes based on conventions, like namespace or some attribute or something.

It doesn't need to be XML - I may be generating routes based on some DSL - but there are lots of reasons; Ability to alter routes without access to code.  Ability for a plugin writer to upload a plugin and associate it entirely through some configuration (perhaps stored in a db) - in any CLR language.   Disambiguation when you have lots of different people or groups contributing.  Flexibility to go outside the conventions for exceptional cases.  Actually, all the same reasons you'd want to put anything in configuration rather than code or convention might apply.     I just happened to run into one of them.

PhilipRieck:

It doesn't need to be XML - I may be generating routes based on some DSL - but there are lots of reasons; Ability to alter routes without access to code.  Ability for a plugin writer to upload a plugin and associate it entirely through some configuration (perhaps stored in a db) - in any CLR language.   Disambiguation when you have lots of different people or groups contributing.  Flexibility to go outside the conventions for exceptional cases.  Actually, all the same reasons you'd want to put anything in configuration rather than code or convention might apply.     I just happened to run into one of them.

I hear you, that is some of the stuff I am working on.  I haven't had as much time to spend on it as I wanted but I should have something for the community soon. 

Hi Philip,

 I am the author of the RouteBuilder HTTPModule, and yes, there was far more code than you would think you would need to do it. Lets hope that v2 cleans that up a lot :)