You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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
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)
The text was updated successfully, but these errors were encountered:
I have been trying to convert a test project in C# that uses interfaces to VB to experiment with this cool tool. I have noticed that the interfaces are not converting correctly to Visual Basic code. I only know this because the conversion produces code that doesn't compile because the code doesn't successfully implement the interface on the VB side. I'm using Code Converter v5.7.0.0 and Visual Studio 2017 v15.7.2 Are interface conversions a supported feature, or will they be supported at a later time?
Yes, interfaces should be converted correctly in general, but it sounds like you've found a bug. If you create a new github issue and fill in the template with the code that's doesn't convert properly, that should give enough information to be able to fix the problem. Ideally post the code for the interface and the class that implements it, since the issue could be with either of them.
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.
Common cases may be implemented on popular request
VB to C#:
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.
C# to VB:
VB to C#
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 #636The text was updated successfully, but these errors were encountered: