For the purposes of this question, the code base is an ASP.NET website that has multiple pages written in both C# and Visual Basic .NET. The primary language is C# and the Visual Basic .NET webpages where forked into the project as the same functionality is needed.
Should the time be taken to actually rewrite these pages, including going through the testing and debugging cycle again, or would the be considered acceptable as is?
Hi,
You may not want to do this. Maintainability will be very difficult in this case, as teams usually have expertise with a single language.
We have had projects here using C# written for some pages and VB.Net for other. Building teams to maintain such projects is difficult.
Kind regards, Ashish
What you are suggesting is a partial rewrite.
I could only advocate a rewrite if there were something severely wrong with the functionality or architecture of the existing code.
A preference for C# over VB is not justification enough IMO.
To answer the first question, yes it is fully acceptable, and supported by Microsoft.
Should you change it? If your developers understand the project situation, then I think are you just fine, but if you start to see issues with namspaces, references, or development teams that can't handle VB (unlikely). Then i would consider re-writing.
But if the code is there and working, it it typically hard to justify re-writing.
There are three points you should keep in mind:
First off, like many have said if it's not broken, then why go through the effort of changing the code base. You risk adding bugs during the language transition, even if they're both .Net languages running in ASP.Net.
Second, I'm going to assume there was a valid reason for forking the project and using VB.Net instead of continuing with C#. What were the reasons behind this language change? Are those reasons no longer valid? Consider the validity of the assumptions that led to forking into a different language.
Third, are all team members competent in C#? Migrating all the code to C# might be a burden if several team members are not proficient in it.
Finally, I would suggest adopting coding standards and focus all new development in one language from this point onward. Along with those standards you might consider a policy dictating that if you need to modify/fix VB.Net pages that this page should be migrated to C#.
At that point the VB.Net page is no longer "not broken" and you'll most likely have to go through the debugging / testing stage anyway to verify the fixes/changes. So you're adding the cost of the migration to whatever bug fix. In this manner you can slowly migrate the code to C# without incurring a large one time cost.
If you balk at the cost of having to migrate a page along with any bug fix or change in a VB.Net page, then take note of this. You most likely don't have the time or resources to do a migration of ALL the VB.Net pages. As a mass migration would require even more time and would sensibly require you halt all work/fixes on the VB.Net pages while the migration is under way. This might be an indicator about whether migrating to C# is an option given your business needs.
It is very well supported.
For pages it makes no difference. Each page is compiled individually.
For code in the App_Code directory it's compiled on a per folder basis. So C# files and VB.NET files need to go in their own separate subfolders. These subfolders need to be noted in the compilation section of the web.config so the compiler knows to treat them differently.
<configuration>
<system.web>
<compilation>
<codeSubDirectories>
<add directoryName="VB_Code"/>
<add directoryName="CS_Code"/>
</codeSubDirectories>
</compilation>
</system.web>
Here's a decent link on it. Using VB.NET and C# in the App_Code folder
The only drawback I've found is that Intellisense doesn't seem to work between the two App_Code subfolders. In the pages intellisense works fine though.