C# -> VB: Better winforms conversion

[GrahamTheCoder]

I tackled similar issues for VB->C# in #540, #547, #550. Here are a few known bugs that occur in converting the standard winforms generated project. They're roughly ordered from easier to harder.

Help wanted

As well as VB's decreasing support from Microsoft and tool vendors, VB has a reputation as a starter/prototype language, but not being so good long term, robust projects. This means the number of people trying to convert a whole winforms project C#->VB is relatively small compared to converting snippets. On top of that, there are major differences in how VB structures winforms code, so there's a large amount of work involved in getting this right.

For those reasons this hasn't been a priority area, only occasionally improved, but if anyone's interested in working on this area I'd be very happy to support them doing so.

There's a May 2019 fork of this project which was itself converted to VB, and may well have fixes for some of these issues:
#8 (comment)
The author is very happy for them to be reintegrated where possible

Details

• DefineConstants in the project file needs to be converted between comma separated (VB) and semicolon separated (CSharp)
• Everything is incorrectly qualified as [global] instead of Global
• Add Option Infer to project file (to allow type inference)
• Convert MultiplyAssignmentStatement
• If one side of an & isn't a string, call ?.ToString() on it
• If result of a division is type int, then use integer division \
• Add default project imports into vbproj (e.g. System)
• Conversion is very slow for large files/projects due to the clashing renamer calling GetCsSymbolsDeclaredByMethod which calls LookupSymbols with a wide scope a lot of times
• Convert invoke method
• All parts of a partial class need the same modifier
• Ensure entry point Sub Main becomes public
• Fix resource references (I think the fix is the same as it was VB->CS)
• CS -> VB Coalesce DefineDebug and DefineTrace into DefineConstants
• Use https://github.com/mashmawy/FastStyleTransfer as test case
• Generate something that works in the designer post-conversion C# -> VB: Form designer changes when i click a form member #593

[ad48hp]

The structure of this codebase seem to very complicated for me yet.
Could you look at repairing it yourself ? Also, i'm quite surprised this got quite w/o a touch for an entire year, there are seemingly very few people that care about this and also have abilities to recode it well..

[GrahamTheCoder]

If you're interested, I've done the tweaks to make the converted code actually run here: GrahamTheCoder/FastStyleTransfer#1

Now there's an expected output for the input, it should be easier for someone to turn into unit tests and fix the individual issues in the converter. I do regard your interest in this as an upvote to work on it, so I'll aim to fix a couple of the more commonly hit issues sometime in June, though can't promise anything specific.

I'm happy to take any specific ideas for making it easier to get started on the project by the way. For example, anything I could add to Contributing.md.

As I mention on the readme, the C#->VB side of things is a bit neglected. It seems there are fewer experienced devs who know both VB and C#, and want to convert in that direction. For VB->C# people seem to more often convert a whole project, whereas for C#->VB, people more commonly seem to use the snippet conversion so they can use things from stack overflow for example. So there's also an element of how much benefit people stand to gain by helping out.

Thanks for your feedback!