Se você leu meus artigos sobre Routing com web forms, ou simplesmente está testando o Routing ou ASP.Net MVC, e resolveu fazer o deploy para o IIS, descobriu que lá a história é outra quando recebe um belo erro 404.

Pois bem, é isso mesmo. O IIS 6 não sabe o que fazer com um request http://localhost/app/controlador/acao/id. Ele vai procurar o diretório, e não vai encontrar. Resultado: erro 404.

Algumas opções:

1. Mapear todos os requests para o filtro ISAPI do ASP.Net. Vai funcionar, mas aí até mesmo imagens e arquivos javascript, html e css vão ser servidos pelo ASP.Net, o que causa um overhead razoável.
2. Utilizar rotas que possuem extensão, como http://localhost/app/controlador.ASPX/acao/id, ou http://localhost/app/controlador.MVC/acao/id. No segundo caso, você também vai ter que mapear .MVC para a extensão ISAPI do .Net.
3. Reescrever a URL. Isso é um hack mesmo, e apesar de funcionar, acho que é demais para um problema tão simples. Você acaba reescrevendo para o IIS requests sem extensão por um filtro ISAPI de terceiros, e depois desfaz a rescrita no ASP.Net. De qualquer forma, se você precisar ir a produção, talvez seja a melhor opção.

Mais informações sobre como fazer essas configurações no blog do Steve Sanderson.

Como as opções são como usar Routing com IIS 6, não coloquei acima a melhor de todas: Migrar para Windows Server 2008 e IIS 7. É mais rápido, mais escalável, mais fácil de administrar, mais plugável, mais extensível, etc, etc, etc. Se você é desenvolvedor, o Windows Vista já vem com o IIS 7.