简体   繁体   中英

How do I integrate a new MVC C# Project with an existing Web Forms VB.NET Web Application Project?

We have a corporate website with a large amount of dynamic business application pages (eg Shopping Cart, Helpdesk, Product/Service management, Reporting, etc.) The site was built as an ASP.Net Web Application Project (WAP). Our systems have evolved over the years to use .NET 4.5 and various custom business logic DLLs (written in a mix of C# and VB.NET). However, the site itself is still using VB.NET Web Forms. We now have done a few side projects in MVC 4 using Razor/C#, and we want to use this framework for new pages on the main corporate site going forward. What would be the easiest way to achieve this?

  • I found this nice list of steps to integrate MVC 4 into an existing Web Forms app . The problem is that because our existing app is a VB.NET WAP, it compiles into a single DLL, and .NET allows only one language per DLL. The site is way too big for us to contemplate converting it to C# all at once (yes, I've looked at the conversion tools, and they're good, but even 99% accuracy would leave us a huge amount of cleanup work.)
  • I thought about converting the existing WAP into a Web Site Project (WSP) which does allow mixing languages and then following the steps above, but after a few pages of Google results, I couldn't find any steps for converting a WAP to WSP. (Plenty of sites offer the reverse steps: converting a WSP to a WAP.)
  • Another idea I had was to create a completely separate MVC project, and then somehow squish them together into the same folder structure, where they would share the bin folder but compile to separate DLL's. I have no idea if this is possible, because certain files would collide (eg Global.asax, web.config, etc.)
  • Finally, I can imagine a compromise solution where we keep all the MVC stuff in its own separate application under a subfolder of the main solution. We already use our own custom session state solution, so it wouldn't be difficult to pass data between the old site to the new pages.

Which of the ideas above do you think makes the most sense for us? Is there another solution that I'm missing?

After some more research and experimentation (and thanks to a suggestion from TS) I have narrowed it down to either the 2nd or 4th option from my initial question:

  1. Convert our WAP to a WSP, and then follow the steps to integrate MVC into the site . I don't see moving from a WAP to a WSP as a complete step backward. As the MSDN link explains, performance does not suffer, and it's mainly a question of how to adjust our build/deployment process. The major advantage with this technique is that it allows multiple languages to coexist in the same project and root folder. Certain files, such as Global.aspx.vb, would have to remain in VB.NET. But specific folders and web pages could be designated as C#. The disadvantage for us is that our site has a lot of legacy pages that use old-style server-side-includes of ASPX page fragmets, and these cause build errors in a WSP. These would have to be changed into User Controls, or perhaps renamed to an unrecognized extension, such as .aspxinclude, so that they are not included in builds.
  2. Create an MVC child application as a new .NET project (see http://support.microsoft.com/kb/307467 ). The parent web.config needs its <system.web> section wrapped with <location path="." inheritInChildApplications="false"> <location path="." inheritInChildApplications="false"> , and the new app's subfolder needs to be converted to an Application via IIS Manager. The child app can be a WAP using a different default language (C# vs VB.NET). This makes it is easier to isolate from our existing project. But this is also a disadvantage because the MVC routing only works on URL's in the subfolder of the child application. So if we wanted multiple parts of our site to use MVC routing, it would require separate child projects, eg (/cart, /myaccount, etc.)

We are probably going to go down the path of option #1, converting to a WSP, and only resort to #2 if we encounter a big obstacle.


UPDATE: I was able to do the conversion using technique #1. It's been working for several months now, so I published a blog post with the procedure I followed.

Came up with a very simple solution.

  1. Create new MVC C# project
  2. Add the old vb project to the solution.
  3. Move the VB aspx pages to the new C# project
  4. REMOVE THE CODE BEHIND ATTRIBUTE FROM THE FIRST LINE OF THE VB PAGES eg...Codebehind="ProductDetails.aspx.vb" (this is the magic)
  5. Add a reference to the VB project in the C# project
  6. This will work for master pages as well

Strangely the VB aspx pages 'just find' the codebehind from the reference and the C# project does not seem to care about the aspx pages being VB.

Go figure!

Hope I saved someone some time. I spent many hours on this.

You have 3 options here:

  1. Convert the ASP.NET Web forms from VB to C#
  2. Convert your MVC 4 written in C# to VB.
  3. Develop all old apps in ASP.NET Web forms again to MVC 4 (ugly but better for future changes)

My advise is keep them diferent projects only share your business logic. And in the same solution file.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM