UrlRewriter.NET with .NET 4.0 not working

Question

I have a web project that had UrlRewriter.NET installed and working fine on .NET 3.5 locally.

I then upgraded it to .NET 4.0 and this continued to work on my local PC in Visual Studio 2010.

When I moved this .NET 4.0 project to my server the url rewriting stopped working.

Here is my web.config (condensed for readability here)

<?xml version="1.0"?>
<configuration> 
   <configSections>
      <section name="rewriter" requirePermission="false" type="Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler, Intelligencia.UrlRewriter"/>
   </configSections>

   <system.web>

   </system.web>
   <rewriter>
      <rewrite url="~/Neat-Url" to="~/Ugly-Url.aspx?id=1"/>
   </rewriter>
   <system.webServer>
       <validation validateIntegratedModeConfiguration="false"/>
       <modules runAllManagedModulesForAllRequests="true">
           <add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule"/>
       </modules>
    </system.webServer>
</configuration>

When put on the server it just returns a 404.

Interesting discovery. If I create a directory called /Neat-Url, the url rewriting starts working again and redirects to /Ugly-Url.aspx?id=1

Note: Yes I realize that .NET 4.0 has it's own url rewriting and I also have existing code that works with UrlRewriter.

So am I doomed because it is a server configuration issue or is there a way I can work around it?

[UPDATE]: Ok so I have determined something else. The url rewriter won't work unless the file or directory actually exists.

For example. If I want to redirect /Directory1 to /Directory1.aspx, /Directory1 must exist, then it all works fine.

If I want to redirect /File1.aspx to /File2.aspx this also works but File1.aspx must exist on the file system.

Otherwise I continue to get a 404. This seems solvable via .NET and has something to do with the web.config as calling upon File1.aspx gets passed to the runtime and gets an asp.net 404. Calling a directory just gets a web host 404.

[UPDATE 2]: I removed the

<httpModules> 

section from my web config, then added

<identity impersonate="false"/>

Then also changed validateIntegratedModeConfiguration="true". Still the same problem but at least is validates in Integrated Mode now.

[UPDATE 3]: I am now trying ManagedFusion yet still running into errors, but it seems more like a configuration error on my part rather than server support. I raised another question ManagedFusion Url Rewriting not working.

Hopefully that will solve my problems.

Answer 1

You can use alternate rewriters that work with .net 4.0 and GoDaddy. Such as the Managed Fusion URL Rewriter and Reverse Proxy.

My guess is that some permission related to GoDaddys medium trust config is causing the inconsistencies you are seeing.

Answer 2

Actually what you want is this. Make sure this setting is false because otherwise after URL Rewriting rewrites the URL, the .NET application might re-route it back.

   <system.webServer>
       <modules runAllManagedModulesForAllRequests="true">

Answer 3

What kind of application pool you are using? UrlRewrite does not work with Classic Application Pool for .NET 4.0, your application pool has to be configured for .NET 4.0 Pipeline mode only.

Answer 4

This answer got UrlRewriter to work on my GoDaddy account:

Can Intelligencia.UrlRewriter be made to work in IIS7?

The solution is to add this to your web.config:

<system.webServer>
  <validation validateIntegratedModeConfiguration="false" />
  <modules runAllManagedModulesForAllRequests="true">
    <add name="UrlRewriter" 
      type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter" />
  </modules>
</system.webServer>

Answer 5

change rewrite module to Url Rewrite Module. I had same problem with Godaddy, so changing is solved my problem.

Answer 6

It seems as though URL Rewriter.NET is not going to play nicely.

It is most likely due to the fact my application runs in a virtual directory.

I did manage to get Microsoft's URL rewriting working (not Url Routing as that also has issues with virtual directories).

So that is what I will use.

I think it is fair to say URLRewriter.NET has had it's day.