Mixing VB ASP.NET and C# ASP.MVC projects in a single solution

Question

Background

We are a TDD team who have inherited a legacy ASP.NET application and are trying to bring it under control by separating presentation, business and data access concerns and thereby improving testability. We have had some success using an MVP pattern for newly added pages but are investigating the MS MVC framework to see if it gives us any benefit over MVP. Importantly, we would want the new MVC work to be in C# while the legacy application is in VB. We have looked at this blog entry which mostly achieves what we want but doesn't allow us to code in C#. Additionally, there are a number of blog entries about partitioning a single web application across multiple projects which looked useful (here)

Question

Can you create a working prototype consisting of a single web application made up of two projects (the default VB ASP.NET project and the default C# MVC project) and have them work nicely together. I have not been able to do this successfully (I think due to routing issues). If you can I'd like to see your web.config and global.asax files.

Thanks in advance

Neil

Answer 1

If you're not doing pure MVC, don't bother. The advantage of the ASP.NET MVC framework is that it separates the layers of an application and gives you more control over each of them. What I think you're doing is launching new functionality in MVC only because it is fresh and new, but you wouldn't use the advantages it gives you. I think it would become even more unmaintainable and this is not the point. This might not be the case, I don't know what is it you're trying to achieve with this MVC project, if so, please elaborate.

Answer 2

The default MVC app contains two important bits of code in the root of the project, and they will need to exist in the root of your app too:

1. The Global.asax - the code behind sets up the all the routing.
2. The Default.aspx - the code behind fires up the MvcHttpHandler, and starts you off down the MVC routes

Both of these will need to be in the root of your website (or be set up in a similar way somewhere) to load up correctly and start handling all the routing properly - you should also ensure that your routes are specific enough not to catch the legacy apps pages.