Mixing ASP.NET MVC with an exisiting WebForms web application project

I had a chance last night to integrate the new cool asp.net MVC with a "normal" web application - it went rather painless. Read the recipe on my work-blog.

Nightly Fun with 301

WARNING: GEEKY STUFF.

 

Do you ever have difficulty falling asleep at night, because your brain begins to code the moment your tired body hits the bed? Well, I do every once in a while. And then I know that I can either toss and turn all night or sneak downstairs and code for a while - just to get it out of my system.

Last night was one of those nights. This time, though, I decided to make something simple but useful. The idea had been in the back of my head ever since I visited a large client recently who was getting ready to move a big and popular web site in the media industry to EPiServer CMS 5.

Basically this is the classic problem that I'm trying to solve: When moving a web site to a new platform it often happens that the url to the individual pages changes which breaks links, search engine ranks and results in a lot of 404 errors. For instance, with Friendly URLS in EPiServer a page that used to be called "/articles/article124145.html" might now get the friendlier path"/News/New+Website+Launched/". So, my solution to this problem is simply a generic HttpModule that loads a series of old-path / new-path sets from a text-file when the web application is started and then makes a quick check for every request to see if it's actually an old URL being requested. If it is, it'll do the correct thing and send back an HTTP 301 Permanently Moved reply with the new location of the document. That way both global search engines and various caches should get updated and no links will be broken. Simple, but it seems to work - and to my luck it was so easy to code that I still got most of a good nights sleep.

 

    public class RedirectModule : IHttpModule
    {
        private Dictionary<string, string> map;

        public void Init(HttpApplication app)
        {
            app.BeginRequest += new EventHandler(app_BeginRequest);
            map = new Dictionary<string, string>();
            //Load from file
            StreamReader sr = File.OpenText(ConfigurationManager.AppSettings["UrlMapping"]);
            string s = null;
            while ((s = sr.ReadLine()) != null)
            {
                string[] parts = s.Split('|');
                if(parts.Length==2)  map.Add(parts[0], parts[1]);
            }
            sr.Close();
        }

        void app_BeginRequest(object sender, EventArgs e)
        {
            HttpApplication app = (sender as HttpApplication);
            if (map.ContainsKey(app.Request.Url.LocalPath))
            {
                app.Response.Status = "301 Moved Permanently";
                app.Response.AddHeader("Location", map[app.Request.Url.LocalPath]);
                app.Response.End();
            }
        }

        public void Dispose()
        {
        }
    }

 

As said - it didn't keep me up all night.

In order for it to work the following adjustments needs to go into web.config:

<appSettings>

  <add key="UrlMapping" value="c:\\inetpub\\UrlMapping.txt"/>


</appSettings>

<system.web>

  <httpModules>


    <add name="RedirectModule" type="EPiServer.Research.RedirectModule.RedirectModule,EPiServer.Research.RedirectModule"/>


  </httpModules> 
</system.web>

 

And the mapping file should just be a series of [path]|[new path], one on each line like this:

/oldpath/article.html|/newpath/newarticle.aspx

/oldpath/oldpage|http://www.google.com/?q=oldpage+topic

WebResource.axd gives 404

My colleague, Michael Knudsen, has been struggling with a customer & partner for several hours now with an annoying problem on an EPiServer 4.62 site just moved to a production server. Finally, after browsing through half the web and getting valuable feedback from most supporters / developers known to man, a simple solution was discovered.

To save other people the agony he's gone through he persuaded me to post the solution here...

 

Problem symptoms:

When clicking on a button in a webform the following javascript error occurs: Webform_Postbackoptions is undefined. A little simple debugging later it turns out that the page in fact did get a 404 when requesting a web resource (javascript) from the server - which is where the method is defined.

<script src="/WebResource.axd?d=14ZW9Y1So0D_eFk6_pguuw2&amp;t=633359999849186250" type="text/javascript"></script>

If you don't know what webresources does there's a good intro here. This problem had us all stunned for a while - lots of theories going through our heads...."It must be a web.config problem - some handlers are interfering with each others", "Perhaps asp.net isn't properly installed on the server", "But it's working on my machine", "Is this using AJAX?", "Can't we just put the dev. server where it works into production", etc. were some of the thoughts going through our heads as the problem took over our common sense.

 

Solution:

Uncheck this checkbox in IIS:

 

 

Skype and Port 80

This is probably old news to a lot of people, but I just ran into an error message in IIS7 on my Vista saying that "The process cannot access the file because it is being used by another process" whenever I tried to start my default website.
Ah well, I thought...Better shut down various other applications although I was wondering what file it could possibly be that there was a sharing conflict on. So, all other app's seemingly shut down, but I still couldn't start my website.
Before I got the error I had been spending numerous hours getting more and more annoyed at IIS7 so I concluded that this was probably something caused by yet another pseudo-paranoid default security setting somewhere - and I guessed that the error was probably misleading and in fact not related to files at all.
Luckily at this point Ruwen came to my rescue and pointed out the obvious that I somehow had missed:
Ruwen: "it could be skype blocking the port 80"

And it turned out that he was (as always) right. Skype listens by default on port 80 and thereby blocks the device (LISTEN on 80) that IIS is using when starting a site.
After visiting Skype's advanced settings and turning off that obscene feature saved my day.