Classic ASP and MVC side by side, different projects?

Question

I tried asking for it in several different ways, but give it another shot (since I haven't received an answer yet, and it silences me!)

I have a very large classic ASP 3.0 application (~ 350 thousand lines) that I want to start migrating to ASP.NET MVC. I would like to keep old ASP files in a separate project from MVC material.

Ideas for debugging them? Should I just dump the files in one folder and create two different projects (WAP and MVC application) that reference the corresponding files and folders required by each of them? This should work, but does anyone have a better idea? I need the ability to transfer small parts of the application separately, as this will probably take a year or two.

Answer 1

Disclaimer , this does not fit my head, I never did this and could be away from the label:

After the initial review, I think you have 3 alternatives that are discussed below:

• Combine in one application,
• Use one application as the root application and the other as a “sub” application
• Copy merge into one application after build (this may not be possible)

1) Merging into 1 application gives you the following advantages: relatively simple, you need to change global.asax - configure mvc, IOC, etc. routes - HttpApplication, Session and Security (accept forms based) will just work.

There is one "minor" problem, and this is sharing tempData, you should be able to create it, if you can create an instance of SessionStateTempDataProvider on your page (Init for loading, unloading to maintain a view similar to the state), I cannot seem to find a blog. but I think it was Steve Sanderson a few months ago.

Testing your module / code coverage will be difficult to track, and you may have to think about ways to manage this, which is a completely different discussion.

2) With this option you will have a complete separation of applications with a new set of inheritance problems. HttpApplication. * May cause a problem if your applications use it because they will refer to different folders, contexts, etc., But ignoring this, stating that you are happy that they are different applications.

The next big problem is getting the sessions to work, now it can be very difficult if the inproc session then each application does not see the other application sessions, however if you use SQL or a custom cache server for the session state you should be able to " hack "procedures or links / configuration and share session state between applications - in the worst case you will need to write your own session provider (I never wrote it, so I don’t know how much it would be or if it’s even practical).

The next problem is forms authentication, you can make standard single sign-on and make sure that MachineKey validation and decryption keys match in the configuration. The tempo data will be the same as option 1. For me it sounds like too many things to change to be viable ...

3) Assuming you take your asp.net website and add a link to mvc and add global asynchronous routing by default, etc., the application should still build cleanly, but throw routing errors when looking for / controller / action / id so you may need to check this out.

Assuming this works, you can “potentially” perform an xcopy merge of the two applications (that is, copy all the files from the mvc application to the pre-deployment of the asp.net application). I know that you can do this by creating one large project when both applications are already combined, but in this way the code is combined at a later stage of the build process. (Signed meetings come to mind as troublesome). And once again you will need to work on the problem of temporary data ...

I did not touch on URL redrawing and many other aspects that you might need, and note that there are various flaws in every approach that you may need.

To summarize, I think your biggest problems will be HttpApplication, Session, and TempData from mvc, see the status from asp.net. URL transfer, authentication should be easier.

And as Forrest Gump said: "These are my thoughts on this."

Answer 2

After many studies, I found that a good way to bring these projects together from the point of view of IIS, but in separate projects in Visual Studio is to create projects in one folder, but save the files for each in their own .csproj files.

Thus, you can publish them separately or as a solution, and I can easily tell by looking at explorer which files belong to each project. Since the elements are moved from the classic ASP (again, NOT .NET) to MVC, I rename the old folders in the ASP project from name to delete-me-name and create the corresponding area in the MVC project.

While this is working. The only other change was to add a route ignore rule in global.asx.cs to ignore .asp files:

  routes.IgnoreRoute("{resource}.asp/{*pathInfo}"); 

So far, everything is working well.