I was recently asked to add an ASP.NET MVC 4 application to an existing Web Forms site. The ideal solution was to keep the code bases separate and the apps on a common domain.
But I wasn’t able to achieve this in a way that would satisfy both requirements and produce simple, easy to understand code without changing any of the standard configurations for both apps. There is a post by Scott Hanselman on this topic, but it is from 2011 and requires significant tinkering with the MVC application. I gave it a go, but kept hitting issues with missing dlls, or web.config errors. Unlikely to work without grief, especially with the next release of MVC.
I had to compromise on something. The first option was to combine the two applications into one. Most likely I would create a new MVC 4 app and add the web forms application to it. But this was going to be a hodge-podge of old and new technologies, code and libraries many dating back to .NET 2.0. It would have ruined one of the goals for developing a new app, to move away from legacy code that is becoming harder and harder to maintain.
The second option was to put the apps on two subdomains. This approach seems simple, use a common cookie for both applications and you’ll be logged in to both. I tried this and all worked well. However, there was one snag; the old web forms application makes extensive use of the session and the session would expire if the user spent most of their time on the MVC application without occasionally visiting the web forms app. Their cookie would still be valid, but the data in session would be gone and exceptions would fly!
I came up a quick and dirty solution to keep the lights on, I don’t claim this to be ideal and will work on finding something better. I added global action filter to “ping” a tiny page on the web forms app every time the user loaded an MVC page. It works for now, and I’ll try to find a more elegant solution.