Looking for a good C# to VB.NET converter
-
Can anybody recommend a good C# to VB.NET converter that can convert entire C# projects? I tried several and none of them produce code that can compile. I need to automate converting several thousand lines of code on a regular basis. Manual tweaking is not an option.
-
Can anybody recommend a good C# to VB.NET converter that can convert entire C# projects? I tried several and none of them produce code that can compile. I need to automate converting several thousand lines of code on a regular basis. Manual tweaking is not an option.
why on earth would you do that? both compile to IL, and are completely interoperable. It should be a crime to take good, working C# code and mechanically convert it to VB.NET. Why not just buy a good obfuscator, if thats the intent?:suss: Anger is the most impotent of passions. It effects nothing it goes about, and hurts the one who is possessed by it more than the one against whom it is directed. Carl Sandburg
-
Can anybody recommend a good C# to VB.NET converter that can convert entire C# projects? I tried several and none of them produce code that can compile. I need to automate converting several thousand lines of code on a regular basis. Manual tweaking is not an option.
Get your C# project really drunk, hit it over the head with a mallet, and that should almost make it stupid enough to pass as VB.NET. As has been said, they both compile to IL, however the C# compiler creates faster code. Add to this that VB.NET is an utter joke, and you're really much better off keeping your C# untainted, and calling it from VB.NET via dlls if you really must lower yourself to using VB.NET. ( Guess who is stuck in VB.NET code again as we speak ? ) No converter will do the job 100%. We routinely convert VB.NET to C#, because we charge double to work on VB.NET projects ( and it's still not worth it ). The converters I have seen still import the VB dll and call VB functions from C#, so once I rip those out and fix that code, I expect a good half days work in getting a project to compile, and another day or so fixing bugs created by straight conversion when VB.NET seems to have some whacky ideas about what constitues good maths. I'm sure that C# -> VB.NET will be easier, as it's a step down. It will still be a partially manual process. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
why on earth would you do that? both compile to IL, and are completely interoperable. It should be a crime to take good, working C# code and mechanically convert it to VB.NET. Why not just buy a good obfuscator, if thats the intent?:suss: Anger is the most impotent of passions. It effects nothing it goes about, and hurts the one who is possessed by it more than the one against whom it is directed. Carl Sandburg
One plausable reason is that he has C# code that will perform a prospective client task, but the client is insistent on VB.NET Cheers, Tom Archer - Archer Consulting Group Programmer Trainer and Mentor and Project Management Consultant
-
why on earth would you do that? both compile to IL, and are completely interoperable. It should be a crime to take good, working C# code and mechanically convert it to VB.NET. Why not just buy a good obfuscator, if thats the intent?:suss: Anger is the most impotent of passions. It effects nothing it goes about, and hurts the one who is possessed by it more than the one against whom it is directed. Carl Sandburg
Because customers want VB.NET samples more than they want C#.
-
Get your C# project really drunk, hit it over the head with a mallet, and that should almost make it stupid enough to pass as VB.NET. As has been said, they both compile to IL, however the C# compiler creates faster code. Add to this that VB.NET is an utter joke, and you're really much better off keeping your C# untainted, and calling it from VB.NET via dlls if you really must lower yourself to using VB.NET. ( Guess who is stuck in VB.NET code again as we speak ? ) No converter will do the job 100%. We routinely convert VB.NET to C#, because we charge double to work on VB.NET projects ( and it's still not worth it ). The converters I have seen still import the VB dll and call VB functions from C#, so once I rip those out and fix that code, I expect a good half days work in getting a project to compile, and another day or so fixing bugs created by straight conversion when VB.NET seems to have some whacky ideas about what constitues good maths. I'm sure that C# -> VB.NET will be easier, as it's a step down. It will still be a partially manual process. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
I want to convert code that demonstrates to how to use a .NET component in VB.NET. Ok?
-
I want to convert code that demonstrates to how to use a .NET component in VB.NET. Ok?
OK, I get it. Look, I'm sorry, but VB.NET is not programming, it's a mental enema. Having said that, I stand by my prior comment - you will not find a converter that will do all the work for you, only one that will give you a broad base to work off. Given how similar the syntax is, if you can't work out how to make the sample compile, you should probably give up programming and become a goat herder. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
Because customers want VB.NET samples more than they want C#.
I've found that dumb managers often want VB.NET because they percieve that it's easier, and therefore easier to find other programmers who can use it. This will change, and in fact, we're having no trouble converting clients to C#, simply by showing them our work and telling them we refuse to work in VB.NET, unless they pay double. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
OK, I get it. Look, I'm sorry, but VB.NET is not programming, it's a mental enema. Having said that, I stand by my prior comment - you will not find a converter that will do all the work for you, only one that will give you a broad base to work off. Given how similar the syntax is, if you can't work out how to make the sample compile, you should probably give up programming and become a goat herder. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
It is not a sample - it is 550 samples (and growing) in three separate products.
-
I've found that dumb managers often want VB.NET because they percieve that it's easier, and therefore easier to find other programmers who can use it. This will change, and in fact, we're having no trouble converting clients to C#, simply by showing them our work and telling them we refuse to work in VB.NET, unless they pay double. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
I will suggest this idea to management on the next "How to Significantly Drop our Revenue" meeting.
-
It is not a sample - it is 550 samples (and growing) in three separate products.
The number of samples is kind of irrelevant - I looked into VB.NET -> C# converters, for the reasons I have given, and I could not find anything that magically converted all the code. I actually spent some time emailing the vendor ( who was very helpful - it's called C-Sharpener, if they have a C# -> VB.NEt tool, I'd certainly recommend it ) about some ways that I thought they could have easily improved their process, but I can see how any converter would err on the side of caution and force you to hand fix anything that it's not going to be sure about. Even then, like I said, VB.NET is weakly typed and C# is strongly typed. I ended up with some divide by 0 errors due to an operation giving a float in VB.NET and 0 in C#, because the int needed to be cast to a float first. These sort of issues are inevitable. If you've written these samples in C# and you need to provide them in VB.NET, then you truly have my sympathy. Is there no way you can turn them into a library for VB monkeys to call ? Then they can have real code in their project, without having to be programmers :-) However, if you're providing a reusable library, you really needed to either cross develop in VB.NET ( painful, I know ), or do it in a dll, for precisely this reason. Still a lot of VB monkeys out there, and they are often working in big corporations that have money to spend ( plus they are more likely to be too dumb to write their own components, VB6 always got by on C++/COM components to do real work, VB.NET will probably continue the tradition ). Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
I will suggest this idea to management on the next "How to Significantly Drop our Revenue" meeting.
LOL - like I said, if you're selling components, then you should make them exposable to VB.NET, because that's where the idiots are. If you're writing stuff from scratch, or even adding to existing code, we've had close to 100% success, and frankly, any work that involves VB.NET, I can live without. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
The number of samples is kind of irrelevant - I looked into VB.NET -> C# converters, for the reasons I have given, and I could not find anything that magically converted all the code. I actually spent some time emailing the vendor ( who was very helpful - it's called C-Sharpener, if they have a C# -> VB.NEt tool, I'd certainly recommend it ) about some ways that I thought they could have easily improved their process, but I can see how any converter would err on the side of caution and force you to hand fix anything that it's not going to be sure about. Even then, like I said, VB.NET is weakly typed and C# is strongly typed. I ended up with some divide by 0 errors due to an operation giving a float in VB.NET and 0 in C#, because the int needed to be cast to a float first. These sort of issues are inevitable. If you've written these samples in C# and you need to provide them in VB.NET, then you truly have my sympathy. Is there no way you can turn them into a library for VB monkeys to call ? Then they can have real code in their project, without having to be programmers :-) However, if you're providing a reusable library, you really needed to either cross develop in VB.NET ( painful, I know ), or do it in a dll, for precisely this reason. Still a lot of VB monkeys out there, and they are often working in big corporations that have money to spend ( plus they are more likely to be too dumb to write their own components, VB6 always got by on C++/COM components to do real work, VB.NET will probably continue the tradition ). Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
I think Igor is running into the crowd that just cuts and pastes example code into production products. Also, they probably want to avoid all the questions like you use += on an event. How do I do that in VB? :^)
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
-
I think Igor is running into the crowd that just cuts and pastes example code into production products. Also, they probably want to avoid all the questions like you use += on an event. How do I do that in VB? :^)
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
andy brummer wrote: I think Igor is running into the crowd that just cuts and pastes example code into production products. Yeah, I had that feeling, but now I'm sort of thinking that he's part of a team that's written a component in C# and want to convert it to VB. He said it's three products, 550 samples *and growing*. If it's growing, surely that means it's their code, and they've made the mistake of not cross developing in VB.NET, assuming they cannot ship it in dlls. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
andy brummer wrote: I think Igor is running into the crowd that just cuts and pastes example code into production products. Yeah, I had that feeling, but now I'm sort of thinking that he's part of a team that's written a component in C# and want to convert it to VB. He said it's three products, 550 samples *and growing*. If it's growing, surely that means it's their code, and they've made the mistake of not cross developing in VB.NET, assuming they cannot ship it in dlls. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
Well, I still think the VB community is going to slowly shrink/stay at current levels while C# is going to keep growing. Hopefully in a few years VB will be in the same place that COBOL is now.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
-
Well, I still think the VB community is going to slowly shrink/stay at current levels while C# is going to keep growing. Hopefully in a few years VB will be in the same place that COBOL is now.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
Yeah, I agree 100%. VB.NET is a dead duck, thank goodness. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
Get your C# project really drunk, hit it over the head with a mallet, and that should almost make it stupid enough to pass as VB.NET. As has been said, they both compile to IL, however the C# compiler creates faster code. Add to this that VB.NET is an utter joke, and you're really much better off keeping your C# untainted, and calling it from VB.NET via dlls if you really must lower yourself to using VB.NET. ( Guess who is stuck in VB.NET code again as we speak ? ) No converter will do the job 100%. We routinely convert VB.NET to C#, because we charge double to work on VB.NET projects ( and it's still not worth it ). The converters I have seen still import the VB dll and call VB functions from C#, so once I rip those out and fix that code, I expect a good half days work in getting a project to compile, and another day or so fixing bugs created by straight conversion when VB.NET seems to have some whacky ideas about what constitues good maths. I'm sure that C# -> VB.NET will be easier, as it's a step down. It will still be a partially manual process. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
Christian Graus wrote: they both compile to IL, however the C# compiler creates faster code Are you sure? I know C++ generates more optimized IL, but I have never heard that C# should make more efficient IL than VB.NET. - Anders Bill's Bar
My PhotosWDevs - The worlds first DSP, free blog space, email and more. Now also with forums :)
-
Christian Graus wrote: they both compile to IL, however the C# compiler creates faster code Are you sure? I know C++ generates more optimized IL, but I have never heard that C# should make more efficient IL than VB.NET. - Anders Bill's Bar
My PhotosWDevs - The worlds first DSP, free blog space, email and more. Now also with forums :)
The guy who told me this was a VB.NET programmer ( the one who threatened to beat me up for saying that VB.NET sucks ), it was in his list of things he wishes would change about VB.NET. Given that he was on the VB.NET side, and pretty vocal, I doubt he'd suggest it if it were not true. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
It is not a sample - it is 550 samples (and growing) in three separate products.
IMNSHO - a sample spit out by an automatic converter, without "manual tweaking" somehow defeats it's purpose. I've done a bit of walking through Fortran-translated-to-C code
I never really know a killer from a savior
boost your code || Fold With Us! || sighist | doxygen -
OK, I get it. Look, I'm sorry, but VB.NET is not programming, it's a mental enema. Having said that, I stand by my prior comment - you will not find a converter that will do all the work for you, only one that will give you a broad base to work off. Given how similar the syntax is, if you can't work out how to make the sample compile, you should probably give up programming and become a goat herder. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
If you judge your programming language by it's syntax then you're easily pleased. I'd rather judge a language on what it can achieve, how it works with other languages, what libraries are available for use and what sort of support is in place for that language. But that's just me. cheers, Chris Maunder