Upgrading a 10 year old site to ASP.NET Core’s Razor Pages using the URL Rewriting Middleware

My podcast has over 600 episodes (Every week for many years, you do the math! And subscribe!) website was written in ASP.NET Web Pages many years ago. "Web Pages" (horrible name) was it's own thing. It wasn't ASP.NET Web Forms, nor was it ASP.NET MVC. However, while open-source and cross-platform ASP.NET Core uses the "MVC" pattern, it includes an integrated architecture that supports pages created with the model-view-controller style, Web APIs that return JSON/whatever from controllers, and routing system that works across all of these. It also includes "Razor Pages."

On first blush, you'd think Razor Pages is "Web Pages" part two. I thought that, but it's not. It's an alternative model to MVC but it's built on MVC. Let me explain.

My podcast site has a home page, a single episode page, and and archives page. It's pretty basic. Back in the day I felt an MVC-style site would just be overkill, so I did it in a page model. However, the code ended up (no disrespect intended) very 90s style PHPy. Basically one super-page with too much state management to all the URL cracking happening at the top of the page.

What I wanted was a Page-focused model without the ceremony of MVC while still being able to dip down into the flexibility and power of MVC when appropriate. That's Razor Pages. Best of all worlds and simply another tool in my toolbox. And the Pages (.cshtml) are Razor so I could port 90% of my very old existing code. In fact, I just made a new site with .NET Core with "dotnet new razor," opened up Visual Studio Code, and started copying over from (gasp) my WebMatrix project. I updated the code to be cleaner (a lot has happened to C# since then) and had 80% of my site going in a few hours. I'll switch Hanselminutes.com over in the next few weeks. This will mean I'll have a proper git checkin/deploy process rather than my "publish from WebMatrix" system I use today. I can containerize the site, run it on Linux, and finally add Unit Testing as I've been able to use pervasive Dependency Injection that's built into ASP.NET.

Merging the old and the new with the ASP.NET Core's URL Rewriting Middleware

Here's the thing though, there's parts of my existing site that are 10 years old, sure, but they also WORK. For example, I have existing URL Rewrite Rules from IIS that have been around that long. I'm pretty obsessive about making old URLs work. Never break a URL. No excuses.

There are still links around that have horrible URLs in the VERY original format that (not my fault) used database ids, like https://hanselminutes.com/default.aspx?ShowID=18570. Well, that database doesn't exist anymore, but I don't break URLs. I have these old URLs store along site my new system, and along with dozens of existing rewrite URLs I have an "IISUrlRewrite.xml" file. This was IIS specific and used with the IIS URL Rewrite Module, but you have all seen these before with things like Apache's ModRewrite. Those files are often loved and managed and carried around for years. They work. A lot of work went into them. Sure, I could rewrite all these rules with ASP.NET Core's routing and custom middleware, but again, they already work. I just want them to continue to work. They can with ASP.NET Core's Url Rewriting Middleware that supports Apache Mod Rewrite AND IIS Url Rewrite without using Apache or IIS!

Here's a complex and very complete example of mixing and matching. Mine is far simpler.

public void Configure(IApplicationBuilder app)

{

    using (StreamReader apacheModRewriteStreamReader = 

        File.OpenText("ApacheModRewrite.txt"))

    using (StreamReader iisUrlRewriteStreamReader = 

        File.OpenText("IISUrlRewrite.xml")) 

    {

        var options = new RewriteOptions()

            .AddRedirect("redirect-rule/(.*)", "redirected/$1")

            .AddRewrite(@"^rewrite-rule/(d+)/(d+)", "rewritten?var1=$1&var2=$2", 

                skipRemainingRules: true)

            .AddApacheModRewrite(apacheModRewriteStreamReader)

            .AddIISUrlRewrite(iisUrlRewriteStreamReader)

            .Add(MethodRules.RedirectXMLRequests)

            .Add(new RedirectImageRequests(".png", "/png-images"))

            .Add(new RedirectImageRequests(".jpg", "/jpg-images"));


        app.UseRewriter(options);

    }


    app.Run(context => context.Response.WriteAsync(

        $"Rewritten or Redirected Url: " +

        $"{context.Request.Path + context.Request.QueryString}"));

}

Remember I have URLs like default.aspx?ShowID=18570 but I don't use default.aspx any more (literally doesn't exist on disk) and I don't use those IDs (they are just stored as metadata in a new system.

NOTE: Just want to point out that last line above there, where it shows the rewritten URL. Putting that in the logs or bypassing everything and outputting it as text is a nice way to debug and developer with this middleware, then comment it out as you get things refined and working.

I have an IIS Rewrite URL that looks like this. It lives in an XML file along with dozens of other rules. Reminder - there's no IIS in this scenario. We are talking about the format and reusing that format. I load my rewrite rules in my Configure() method in Startup:

using (StreamReader iisUrlRewriteStreamReader = 

        File.OpenText("IISUrlRewrite.xml")) 

{

    var options = new RewriteOptions()

        .AddIISUrlRewrite(iisUrlRewriteStreamReader);


    app.UseRewriter(options);

}

It lives in the "Microsoft.AspNetCore.Rewrite" package that I added to my csproj with "dotnet add package Microsoft.AspNetCore.Rewrite." And here's the rule I use (one of many in the old xml file):

<rule name="OldShowId">

    <match url="^.*(?:Default.aspx).*$" />

    <conditions>

        <add input="{QUERY_STRING}" pattern="ShowID=(d+)" />

    </conditions>

    <action type="Rewrite" url="/{C:1}?handler=oldshowid" appendQueryString="false" />

</rule>

I capture that show ID and I rewrite (not redirect...we rewrite and continue on to the next segment of the pipeline) it to /18570?handler=oldshowid. That handler is a magic internal part of Razor Pages. Usually if you have a page called foo.cshtml it will have a method called OnGet or OnPost or OnHTTPVERB. But if you want multiple handlers per page you'll have OnGetHANDLERNAME so I have OnGet() for regular stuff, and I have OnGetOldShowId for this rare but important URL type. But notice that my implementation isn't URL-style specific. Razor Pages doesn't even know about that URL format. It just knows that these weird IDs have their own handler.

public async Task<IActionResult> OnGetOldShowId(int id)

{

      var allShows = await _db.GetShows(); 


      string idAsString = id.ToString();

      LastShow = allShows.Where(c => c.Guid.EndsWith(idAsString)).FirstOrDefault();

      if (LastShow == null) return Redirect("/"); //catch all error case, 302 to home

      return RedirectPermanent(LastShow.ShowNumber.ToString()); // 301 to /showid

}

That's it. I have a ton more to share as I keep upgrading my podcast site, coming soon.

Sponsor: Get the latest JetBrains Rider for debugging third-party .NET code, Smart Step Into, more debugger improvements, C# Interactive, new project wizard, and formatting code in columns.