views:

620

answers:

6

Are there any 'good' resources for porting a VB.NET winforms application to C#? I'm sure there are is software that just translates the code, but I'm looking to refactor the code at the same time. Keeping it in its current form is problematic, since it uses some of the 'bad design' practices that VB.NET allows, and would further complicate future maintanence. Has anyone here gone through that process, and how did you go about doing it? Did you use a translate/refactor approach? Did you just use the end product to recreate functionality without looking at the current codebase for most of it? What would you (collectively) recommend?

Update:

As I was telling Grauenwolf, keeping it in its current language presents the following issues:

  • Not being able to readily add features. VB.NET isn't a language I'm rock solid in. I do appreciate the irony of learning the language to port it over -- but future maintenance will need to account for someone who doesn't know VB.NET.
  • The rest of the application has been ported to C# (a long time ago, in fact); all features that we'd like to add depend on de-coupling the app (right now it's very tightly coupled). My choices are to either refactor it in a language I'm not too familiar with, or to refactor it in a language I understand.

To anyone who voted the question down, I'm not really sure why you did; the concern isn't whether I should leave it in VB.NET; the concern is what is the future cost of not porting it over now. If I'm going to spare great expense in fixing it, why not go the extra step and make it maintainable for a future programmer?

Author's Note: I hadn't looked at this question in ages, there was a recent response, so I moved my 'answer' into the question and deleted the 'answer' (since it wasn't really an answer).

+5  A: 

If you use something like Reflector or Anakrino, its output is based on the IL rather than the original source. Whether or not it produces code that's any better is open for debate... But you could try it out, anyway. :)

GalacticCowboy
I agree - Decompile to C# and then refactor the results, should be no need to translate it at all.
Brian Schmitt
The latest version of Reflector lets you "optimize" the decompiler for different versions of the framework, and in several different languages. Very cool.
GalacticCowboy
+9  A: 

Based on my experience working with some large applications that mix VB and C# projects, I would recommend leaving it in VB.NET. If there are problems with the design, then fix them, but converting the whole thing to C# sounds like a messy, unnecessary distraction to me.

The non-stylistic differences between the two languages are very minimal, so it is hard to see a functional need that would force a conversion. (There was an old bug in Visual Studio 2003 that ruled out certain chains of project references that mixed C# and VB projects in specific ways, but that is the only one I have ever run into as a practical obstacle.)

Individual developers certainly tend to have a stylistic preference favoring one or the other, but a full conversion is a lot of work to do for something that amounts to a taste for a different flavor of syntactic sugar.

McKenzieG1
I posted more information in an answer to the question below. Also, and I don't know if this is related, but any time I click on 'Go to Defintion' for a C# component that we wrote (one that's inside of another project in the same solution), it pulls up the object browser instead of definition.
George Stocker
Any more thoughts?
George Stocker
The spotty inability to hop back and forth between C# and VB.NET projects via "Go to definition" is definitely an annoyance. On the flip side, VB.NET's incremental compilation is really nice (although using ReSharper does improve things for C#).
McKenzieG1
Bottom line for me is that being 'bi-lingual' in VB.NET and C# is really pretty trivial - the libraries are identical and the languages are very, very similar. If you try it I suspect you will find it easier than you think.
McKenzieG1
+1  A: 

I've used C-Sharpener to do the conversion on some of our apps, but it is far from perfect. It converted roughly 95% of the code, and I ended up refactoring while I was manually fixing the remaining 5%.

Whytespot
+1  A: 

In my job we've used the translator of developerfusion, but nothing automated (just translate the piece of code or the class, and manually paste the result in the c# project).

Reflector is a great tool, but you can find some problems when reading lambda functions.

For refactoring, the best tool we've tried is Refactor Pro.

mapache
+3  A: 

Keeping it in its current form is problematic, since it uses some of the 'bad design' practices that VB.NET allows, and would further complicate future maintanence.

And you think C# won't allow for bad designs?

The problem isn't VB, the problem is the guy who wrote it and the guy refusing to fix it. So take a step back, breath deeply, then start fixing the code. And who knows, you may learn that some of those 'bad design practices' actually make a lot of sense.

Jonathan Allen
+1  A: 

I have some experiences on VB.NET about 2 years, but now I only use C# in my daily development. Before I tried to use VB.Net to C# to convert my VB.NET code to C#, then I learned from it and also from the book.

Samnang