I primarily write in C#, but I have a few legacy apps in VB.Net. While I’ve never really liked using VB.Net there wasn’t much of a need to convert to C#, since it would probably be costly. However, I recently found myself writing code in my C# MVC apps that was duplicating the VB.Net code and I decided it was time to merge the two apps. While you can have MVC and ASP.Net in the same project, you cannot have C# and VB.Net, so it was time for the dreaded conversion. While the method I choose worked, there were a few problems so read carefully before attempting.
Conversion Method
To convert C# you have a few options:
- Use one of the online converters that do page by page conversion. A few do multi-page conversions, but none that I could find did a whole project or solution. Also, I didn’t like giving my source code out.
- Buy a VB.Net to C# converter. The cheapest one I found was for $200 or so. A little Googling will find them.
- Do it for free using SharpDevelop, an open source version of Visual Studio.
I choose SharpDevelop since it was free.
Performing the Conversion
Doing the conversion is relatively easy.
- Make a copy of your solution or project. They will do the conversion into a new project, but I like to create pristine copies when I do conversions like these.
- Open the project in SharpDevelop.
- Go to the Project menu.
- Select Convert (Matt Ward has a good example of how to do it.).
- Wait. The project I converted had perhaps 50 web forms and user controls, with another 10-15 modules and classes. It must have taken 15-20 minutes.
Post Conversion Issues
When I reopened the project in Visual Studio 2010 I had something like 1500 errors. They tended to break down into several categories.
Linq queries: It seems that SharpDevelop always mangled Linq, removing the space from the entity name and where clause and deleting the select completely. So that what should have been
p from ent where p.id = x select p;
became
p from entwhere p.id = x;
Another problem was string manipulation. The code base used many of the VB only methods such as Trim( string). While the conversion engine included a using VisualBasic reference on each page the code appeared, it caused other problems and this was supposed to be a C# program so, I removed the VisualBasic reference and created a series of static helper methods to replace the missing VB ones. For example,
public static string Trim( string str){
return str == null ? str : str.Trim();
}
The most pernicious issue, though, was typecasting. The original developer didn’t understand types very well and did a lot of bad things like store numeric values in the database as chars. VB.Net, if you aren’t careful, will let you get away with that kind of slop (we’ve never had time to do a refactoring to deal with it either). So when it came to accessing data from the database, I had to add a bunch of new casts.And in more than a few occasions the cast made the boolean nature of if statements fail so I had to do a little refactoring.
Finally, the trickiest issue is that all the even handlers for page controls broke. I had to go through and add the onclick even handler to each control, which included buttons, LinkButtons and GridViews (mostly for sorting). It also meant that every button, etc had to be clicked and updated. The problem occurred because the onclick wasn’t defined in the design view, but in the code behind.
Conclusion
Should you do it? I think it is worth while if you have the time. If you have and the code is strictly typed it probably won’t be too painful. I wouldn’t do it the project is always going to be a stand alone, because this touches every line of code and requires one to extensively test afterwards.
