VB -> C#: Many Compiler Errors after Conversion

[wfrx]

We have a giant solution of more than 1031 projects, 713 of which are VB.NET.
We want to convert all our code to C#, so we've tried converting a few projects with the DotNet Tool, but the result is barely usable.
It is of course to be expected that it doesn't work flawlessly and manual adjustments will be necessary afterwards, but most of the errors we encounter are in very basic parts of the code. It seems strange that these conversions would not be supported out of the box.

We are currently looking at different approaches to work around or fix these issues, but I would like to know if the problems we're encountering are to be expected or if they are due to the way our code/solution is structured. Because again, to me they seem mostly like basic VB.NET syntax that should be easily converted into the C# equivalent.

Using the online Converter: https://icsharpcode.github.io/CodeConverter/, it seems that these Problems do not occur.

The following problems make up most of the issues I have encountered so far:

VB.Net input code

'0. Missing Imports/using
Imports Company.Namespace
'1. Method without Parentheses
MyClass.MyMethod
'2. Wrong Case in VB
MyClass.myProperty
'3. Array Indexed Access
MyArray(key)
'4. Generic Types and Nullable Types
IEnumerable(Of Object)
List(Of Integer?)
'5 Optional Method Parameters
Public Sub MyMethod(para1 As Integer, <Out> ByRef Optional myPara As MyType = Nothing)

Erroneous output

//0. Missing Imports/using

//1. Method without Parentheses
MyClass.MyMethod;
//2. Wrong Case in VB
MyClass.myProperty;
//3. Array Indexed Access
MyArray(key);
//4. Generic Types and Nullable Types
IEnumerable;
List<int>;
//5. Optional Method Parameters
public void MyMethod(int para1, [Optional] [Out] ref MyType myPara)

Expected output

//0. Missing Imports/using
using Company.Namespace;
//1. Method without Parentheses
MyClass.MyMethod();
// 2. Wrong Case in VB
MyClass.MyProperty;
//3. Array Indexed Access
MyArray[key];
//4. Generic Types and Nullable Types
IEnumerable<object>;
List<int?>;
//5. Optional Method Parameters
public void MyMethod(int para1, out MyType myPara = null)

Details

• Product in use: dotnet tool ICSharpCode.CodeConverter.CodeConv
• Version in use: 9.2.7.792

[GrahamTheCoder]

There's code to specifically deal with all those issues in the converter. If you used the command line, did it say anything about errors before compilation or "best effort"?
It sounds like you're hitting an issue where the converter ends up running in the wrong mode (e.g. it runs in dot net core but tried to convert framework stuff), or fundamentally has a broken compilation served to it.
With a solution that size are there any other details like nonstandard configurations and conditional compilation symbols?
It defaults to the Release configuration on command line (but can be overridden), or the active one within VS.

I'd tend to prefer the in-vs approach since it's been tested more. If you can isolate a specific contained situation that doesn't work and raise an issue I'll see if I can point to the issue. Like if you make a one or two file solution that compiles before conversion but still has a conversion issue, I can try to help.

[GrahamTheCoder]

Also, I'd suggest generally starting at the bottom of your project dependency tree. I.e. something with no dependencies, and working upwards.
I.e. Forget about all except one project until you've figured out what's messing it up

[wfrx]

Yes, that's probably the best approach. I went back to the first project in our tree, which is an almost empty "anchor" project, that looks like this (I already simplified it a little bit to reduce variables, see commented line). I tried another project with no references but a bit more logic and that had basically the same issues, and in addition a few occurrences of the "[Out] ref" problem described above.

I've been using the CLI Tool because we want to build our own Tooling on top to automatically do things like git rename and commits between steps etc.

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <ProjectGuid>{MyGuid}</ProjectGuid>
    <OutputType>Library</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <RootNamespace>MyCompany</RootNamespace>
    <AssemblyName>MyCompany.Anchor</AssemblyName>
  </PropertyGroup>
  <!-- <Import Project="..\..\_Autobuild\MsBuildTargets\VbProj.Default.props" /> -->
</Project>

It contains only two classes:

Assembly.vb

Imports System.Reflection
 
Namespace Assemblies
 
  <HideModuleName>
  Public Module MyAssemblyAnchor
    Public ReadOnly Anchor As Assembly = GetType(MyAssemblyAnchor).Assembly
  End Module
 
End Namespace

DirectoryAnchor.vb

Namespace Anchor

  Public NotInheritable Class DirectoryAnchor
 
    Private Sub New()
 
    End Sub
  End Class
 
End Namespace

It compiles fine.

I create a new sln and add the project:
dotnet new sln -n "Anchor"
dotnet sln Anchor.sln add Anchor.vbproj

Trying the conversion using codeconv Anchor.sln --core-only gives me errors:

Used MSBuild 8.0.417.
 
    1 workspace errors:
    MSBuild error while processing the file "C:\projects\Source\DotNet\Anchor\_\Anchor.vbproj" with the message: C:\Program Files\dotnet\sdk\8.0.417\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets: (90, 5): Unexpected error in the ProcessFrameworkReferences task.
    System.IO.FileLoadException: Could not load file or assembly 'NuGet.Frameworks, Version=6.11.1.2, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Could not find or load a specific file. (0x80131621)
    File name: 'NuGet.Frameworks, Version=6.11.1.2, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
     ---> System.IO.FileLoadException: Could not load file or assembly 'NuGet.Frameworks, Version=6.11.1.2, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
       at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
       at System.Runtime.Loader.AssemblyLoadContext.ResolveUsingLoad(AssemblyName assemblyName)
       at System.Runtime.Loader.AssemblyLoadContext.Resolve(IntPtr gchManagedAssemblyLoadContext, AssemblyName assemblyName)
       at Microsoft.NET.Build.Tasks.ProcessFrameworkReferences.<>c.<AddPacksForFrameworkReferences>b__217_0(ITaskItem item)
       at System.Linq.Enumerable.SelectArrayIterator`2.MoveNext()
       at System.Linq.Enumerable.WhereEnumerableIterator`1.ToList()
       at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
       at Microsoft.NET.Build.Tasks.ProcessFrameworkReferences.AddPacksForFrameworkReferences(List`1 packagesToDownload, List`1 runtimeFrameworks, List`1 targetingPacks, List`1 runtimePacks, List`1 unavailableRuntimePacks, List`1& knownRuntimePacksForTargetFramework)
       at Microsoft.NET.Build.Tasks.ProcessFrameworkReferences.ExecuteCore()
       at Microsoft.NET.Build.Tasks.TaskBase.Execute()
       at Microsoft.Build.BackEnd.TaskExecutionHost.Execute()
       at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(TaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask).
 
    6 MyCompany.Anchor compilation errors:
       BC30002: Type "System.Void" is not defined.
       BC30652: A reference to the assembly "<Missing Core Assembly>, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null" containing type "Object" is required. Add a reference to the project.
       BC30002: Type "Assembly" is not defined.
       BC30002: The type "HideModuleName" is not defined.
       BC35000: The requested operation cannot be performed because the runtime library's Microsoft.VisualBasic.CompilerServices.StandardModuleAttribute..ctor function is not defined.
       BC31091: Error importing type "Type" from the assembly or module "MyCompany.Anchor.dll".

Doing the best-effort conversion gives me the following result:

Assembly.cs

namespace MyCompany.Assemblies
{ 
    [HideModuleName]
    public static class MyAssemblyAnchor
    {
        public readonly static Assembly Anchor = typeof(MyAssemblyAnchor).Assembly;
    } 
}

With Compiler Errors: HideModuleName and Assembly are not defined, so I need to add using System.Reflection; and using Microsoft.VisualBasic;

[GrahamTheCoder]

Yeah that error Type "System.Void" is not defined. definitely means the references to system assemblies are stuffed. --core-only was intended to avoid that happening, so I don't really know how it manages to end up unable to reference System.Void.

This seemed to change in more recent versions of dot net, so I did actually make a start on ripping out all the framework related hacks in the hope of fixing this sort of issue:
#1196
Since you're building an app around it for a major conversion, you might find that using the core library directly (which doesn't contain any framework specific hacks) is actually viable for you. But you'll still need some sort of code that creates an MSBuildWorkspace (like the command line does).

I'll see if I have time this weekend to get that branch to a state where you can try it

[GrahamTheCoder]

I've merged #1196 now if you want to try running it from source. Would be great to know if it fixes some of the issues you're seeing before I release it fully.
If you have dotnet 10 installed and grab the latest master branch, it should just be a case of running

dotnet build CodeConverter.sln
.\codeconv\bin\debug\net10.0\ICSharpCode.CodeConverter.CodeConv.exe "path/to/your.sln" 

[wfrx]

Thanks for the quick reply. That is looking much better!

I tried that Anchor project and a few different projects with a few more dependencies and overall it looks much much better. large projects still have some compilation errors, but at least some are obviously due to our codebase/project structure, but others seem to be due to the conversion. I will continue to analyze and document the problems I encounter and keep reporting. (I guess opening new issues here for specific problems is better?)

A few larger projects I tried, did start converting but then failed with a long callstack

[GrahamTheCoder]

Fantastic, thanks for trying that. Yes individually reproable focused issues are usually best. Though sometimes things are tangled in a way that's hard to isolate (ahem, winforms).

I've captured the one you mentioned as #1208 - I expect it'll be straightforward to fix from the stack trace in this case, but I'm a bit surprised existing tests didn't catch it, so I'll follow up if I need a code snippet or your VS/dotnet versions.