I’ve tried asking this in a few different ways, but let’s give it another shot (as I’ve yet to receive an answer and this is driving me nuts!)
I have a very large classic ASP 3.0 application (~350K lines) that I want to start migrating to ASP.NET MVC. I’d like to keep the old ASP files in a separate project from the MVC stuff.
Ideas on how to debug these? Should I just dump the files in the same folder and create two different projects ( a WAP and an MVC app) that reference the relevant files and folders required by each? This should work, but does anyone have a better idea? I need the ability to migrate small parts of the application individually as this will probably take a year or two to complete.
Disclaimer this is off the top of my head, I have never done this and could be way off the mark:
After initial review, I think you have 3 alternates discussed below:
1) Merge into 1 application gives you the following benefits, relatively simple you need to modify the global.asax – setting up your mvc routes, IOC etc – HttpApplication, Session and Security (assume forms based) will just work.
There is one somewhat “minor” issue and that is sharing tempData, this you should be able to create if you can instantiate a SessionStateTempDataProvider on you page (Init to load, unload to save similar to view state), I cant seem to find the blog, but think it was Steve Sanderson a few months back.
Your unit testing / code coverage is going to be hard to track and you may need to think of ways to manage that, which is a completely different discussion.
2) With this option you will have complete separation of applications with a new inherit set of problems. HttpApplication.* could cause an issue if your applications use it, because they would reference different folders, contexts etc, but ignoring that stating that you are happy that they are different applications
The next big issue is to get Sessions working, now this could prove to be very tricky, if session is inproc then each application will not see the other applications sessions, however if you are using SQL or custom caching server for session state you should be able to “hack” either the procedures or references/configuration and share the session state between applications – worst case you will need to write your own session provider, (I have never written one so don’t know how hard this will be or if its even practical).
The next issue is forms authentication, you can do standard single sign on and ensure that the MachineKey validation and decryption keys are the same in the configuration. Temp data is going to be the same as option 1. To me this sounds like too many things to change, to be viable…
3) Assuming that you take your asp.net site and add a reference to mvc and add in your default global asax routing etc, the application should still build cleanly but throw routing errors when looking for /controller/action/id type routes, so you may need to check this.
Assuming that works, you could “potentially” do an xcopy merge of the two apps (i.e. copy all the files from the mvc application into the asp.net application pre deployment). I know you can do this by creating one big project with both applications already merged, but this way the code is combined at a much later stage in the build process. (Signed assemblies, come to mind as being troublesome). And once again you will need to work on the temp data issue…
I haven’t touched on url re-writing and many other aspects you may need to consider, and please note there are distinct disadvantages with each approach which you may need to consider.
To sum up I think that your biggest issues will be HttpApplication, Session and TempData from the mvc side, view state from the asp.net side. Url re-writing, authentication should be easier.
And as Forrest Gump said, “That’s my thoughts about that”.