3

We have a corporate website with a large amount of dynamic business application pages (e.g. 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 (e.g. 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?

Community
  • 1
  • 1
Jordan Rieger
  • 3,025
  • 3
  • 30
  • 50
  • 1
    I think, you're cooked. First of all, converting WAP to WSP is worst idea ever. Yes, you can have `WebForms` and `MVC` in same project. Not in your case of course but generally. You create proj as WAP and then reference MVC libraries. Then go to `proj` file and add templates ids. This way you have full capabilities of MVC project. But in your case you use 2 different languages. You can run these as parent-child application. Google on how to setup parent-child asp.net application. In Parent-child they can have two different languages and yet share same security, etc. – T.S. Jun 12 '14 at 21:31
  • With parent-child you also can run different versions of .net. Only some extra config is needed. Read ASP.NET 4 Child Applications Fail to Start When Under ASP.NET 2.0 or ASP.NET 3.5 Applications : http://www.asp.net/whitepapers/aspnet4/breaking-changes – T.S. Jun 12 '14 at 21:37
  • That sounds basically like the 4th option I listed. Probably the least painful for us. Thank you, I will read up on child applications. – Jordan Rieger Jun 12 '14 at 21:41
  • Than be it. option 4 - here we go. you have your answer. – T.S. Jun 12 '14 at 21:44

3 Answers3

3

After some more research and experimentation (and thanks to a suggestion from T.S.) 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">, 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, e.g. (/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.

Jordan Rieger
  • 3,025
  • 3
  • 30
  • 50
0

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.

pat capozzi
  • 1,412
  • 1
  • 20
  • 16
  • Correct me if I'm wrong, but doesn't this technique put the application in a sub-folder rather than the root? That may not be acceptable if the goal is to make the transition seamless, and simply allow new MVC pages within the URL structure of an existing site. – Jordan Rieger Jun 16 '15 at 19:40
  • Also, bear in mind that, depending on the complexity of the existing VB.NET Web Application Project, you may have to deal with non-page class files, inter-page references, and .asmx web services, which pose special conversion challenges. These are addressed in the procedure I developed at http://blog.webnames.ca/updating-vb-net-asp-net-web-application-project-support-c-mvc/. – Jordan Rieger Jun 16 '15 at 19:42
  • You have one application (the MVC application). The VB pages are copied to that application (without the code behind). You can then use them as is or in my case add features into the pages using jquery loads into divs and new MVC pages – pat capozzi Jun 17 '15 at 21:08
-2

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.

mijail
  • 385
  • 1
  • 5
  • I didn't say beautiful and easy options. Sometimes you must suffer to see the light at end of tunnel. – mijail Jun 12 '14 at 21:26
  • 1
    App migrations are painful and full of problems everywhere. – mijail Jun 12 '14 at 21:30
  • It's not really an option for us to convert the whole existing site from VB to C# or from Web Forms to MVC. It's also not an option to write new MVC code in VB because developer mindshare has already moved to C#. – Jordan Rieger Jun 12 '14 at 21:32
  • I know Its expensive in money and time. So you should put all possible business logic in dlls and reuse. And put them in the same solution file, nothing else can be done. – mijail Jun 12 '14 at 21:37
  • Yes, we actually have many separate business logic DLL's already. But there is still a large amount of Web Forms code-behind in VB.NET. Too much to convert or move out. – Jordan Rieger Jun 12 '14 at 22:00