Timeline for Convert a team from VB.Net to C#.Net
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2017 at 16:45 | comment | added | JeffO | @BgrWorker - Many C# programmers would rather cut off their arm than deal with VB, but you're right, it's not due to any complexity. | |
| Apr 6, 2017 at 9:55 | comment | added | BgrWorker | Also, it's fairly trivial for a C# programmer to at least understand VB.NET code. If they can't understand it, don't even let them through the door. | |
| Apr 5, 2017 at 7:14 | vote | accept | aaroncatlin | ||
| Apr 3, 2017 at 14:06 | vote | accept | aaroncatlin | ||
| Apr 5, 2017 at 7:14 | |||||
| Apr 3, 2017 at 13:47 | comment | added | Machado | +1 for "Don't convert code just for the sake of converting it. You may have apps no one will ever look at again.". Also, +1 for @DocBrown comment. It's a good/successful approach which I've used in a few projects in the past. | |
| Apr 3, 2017 at 13:26 | comment | added | Sign | When you get to converting a specific app at least look at the code that is generated by compiling the VB.net code and decompiling it back to C# if you have object oriented VB.net code and aren't using one or two specific features that don't convert well it comes out as reasonable C# code. Refactoring working C# code is easier than converting it all by hand. | |
| Apr 3, 2017 at 12:49 | comment | added | Doc Brown | This answer goes definitely into the right direction, so +1, but I would put much more emphasis on "Don't convert code just for the sake of converting it". For example, in step 2, I miss a suggestion like "try if the changes can be written inside a separate C#-DLL, so one can avoid any pointless conversion of the existing VB.NET parts". | |
| Apr 3, 2017 at 12:27 | history | answered | JeffO | CC BY-SA 3.0 |