The Lanham Factor

I would strongly recommend against such an approach for (At least) two reasons.

1) If you have working code in any CLR based language, simply reference that assembly from your new code written in any other CLR based language. There is no need for migration. This is one of the biggest strong points of .NET

2) There are significant diferences between "optimal representations" and design architectures between the different languages taht ANY conversion process is going to yield sub-optimal results.

I recently demanded a refund on a professional toolkit (with source) that was "written in C#". It was immediately obvious that it was NOT designed following anything even remotely resembling "best practices" for C# development (and was recognizable as the output from one of the "better" VB.Net->C# conveters (I know this is the opposite direction from what you are looking for).

So if you really "need" VB.NET code, then properly architect/design and implement VB.Net code, in the long run you will be glad you did.

This probably isn't much help, since I don't know what you need converted, but I've always been leery of convertors. I do all mine by hand when I need to convert something. Otherwise if I'm just consuming something, I just reference the existing assembly.

I think what you really need is a flux capacitor

use the "reflector" tool. it is free and you can easily convert
from C# to VB.NET and vice versa. Actually it is a decompiler tool but it also serves as a converter.