Visual studio versions

For the VS extension, only VS2019 and VS2022 are supported. Since there is a free version of VS2022 community edition, it isn't worth the effort to continue supporting older versions which can instead be directed to better quality code conversion - the main purpose of this tool.

If you have a project type that doesn't even load in VS2019+, you can try the command line converter, or manually install 8.5.0 - the last release that supported VS2017.

Conversion issues

For discovering issues, the easiest way is to put other open source projects through the converter. One good example is this attempt to use all types of C# syntax in one file.

Awaiting user request/repro/confirmation

These should be broken out into actual issue descriptions when a repro is available.

• MyNamespace.Dynamic .designer.cs not created for sdk-style project
• Type conversion may not work for attribute constructors that take an enum but have integer and object overloads

Common cases may be implemented on popular request

• #Pragma preprocessor directives
• Many different project types exist (ASP NET, Winforms, WPF, MAUI, etc.). The project file conversion just applies some simple transforms to the xml - I know of no more general approach (there's nothing similar to the roslyn library for editing those files), so each special case that differs between vb and cs must be fixed as it's found.
• Non-compiling solutions (e.g. missing references).
  • In general this is an impossible problem to solve, because the information just isn't present, but if there are particularly common cases where we could use a heuristic to guess correctly more of the time, their implementation will be considered.

VB to C#:

• Exponentiation (^) and Like operator overloads cannot be converted, there is no equivalent
  • It would be possible to turn them into normal methods, and call those methods from other code that's being converted, though the public API would be different.

Very unlikely to happen

These things have no direct equivalent in the target language, and are therefore difficult to convert, and even if converted would probably yield ugly code. Therefore they are unlikely to be worked on unless there's significant need for them.

Please comment if you want to encourage others to work on, or work on yourself, or have an idea for how a subset of the functionality could be simply implemented to cover common cases.

• Using statements removed in snippet conversion when the referenced library isn't known, but part of the namespace is: VB -> C#: Non-compiling using directives removed #529
  • This is unsolvable in general since arbitrary libraries can extend any namespace

C# to VB:

• #if directives C# -> VB: If pre-processing directive contents are not converted. #489
• Unsafe code cannot be converted in general, there is no equivalent
  • The recommended approach would be to move the unsafe code into a C# assembly and reference it there. This usually works well since it's usually low level code with few dependencies.
  • Note: In some cases, you may be able to use Span and Memory rather than pointers to avoid needing unsafe
• Syntax from beyond C# 8 isn't supported. There are no plans to do so, though I'm happy to assist someone in learning what's needed.

VB to C#

• Late bound calls: In VB If you pass an object type as a parameter where there are two possible non-object overloads, the compiler calls NewLateBinding.LateCall at runtime to decide which method to call. Before converting to C#, these should be converted manually to resolve the overload at compile time. VB -> C#: Late bound implicit conversion creates compile error #636
  • Considering using dynamic to solve some of these cases, though will likely be imperfect: VB -> C#: Simple boolean eval function breaks on dynamic storage object #782, VB -> C#: Action lambda breaks #783, VB -> C#: Object/dynamic Function breaks #786
• Checked/unchecked operations. e.g. I think For...To loop always uses unchecked addition so it can wrap around (I've avoided doing this since it will make the extremely common case uglier for the sake of a very rare (probably usually accidental) case
  • In scope: May need to ensure that the csproj gets the checkforoverflowunderflow property set to the opposite value compared to VB's RemoveIntegerChecks property (taking into account potentially different defaults)