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
{{ message }}
Repository navigation
VB -> C#: Many Compiler Errors after Conversion #1205
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.
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.
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
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.
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:
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
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
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
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.
Activity
GrahamTheCoder commentedon Feb 5, 2026
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 commentedon Feb 5, 2026
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 commentedon Feb 5, 2026
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.
It contains only two classes:
Assembly.vb
DirectoryAnchor.vb
It compiles fine.
I create a new sln and add the project:
dotnet new sln -n "Anchor"dotnet sln Anchor.sln add Anchor.vbprojTrying the conversion using
codeconv Anchor.sln --core-onlygives me errors:Doing the best-effort conversion gives me the following result:
Assembly.cs
With Compiler Errors:
HideModuleNameandAssemblyare not defined, so I need to addusing System.Reflection;andusing Microsoft.VisualBasic;GrahamTheCoder commentedon Feb 5, 2026
Yeah that error
Type "System.Void" is not defined.definitely means the references to system assemblies are stuffed.--core-onlywas 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 commentedon Feb 6, 2026
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 commentedon Feb 6, 2026
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 commentedon Feb 6, 2026
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.
wfrx commentedon Feb 18, 2026
With the latest Version of the dotnet tool the issues are fixed. This issue is thereby solved.