CodeConverter: moving a codebase between VB.NET and C#

Four ways to run the same converter

CodeConverter is one engine delivered four ways, and knowing which one you want saves time.

The Visual Studio extension is the fullest option. It adds context menu items to convert projects or files between VB.NET and C#, and the download comes from the Visual Studio Marketplace as a VSIX file that you install by closing Visual Studio and double clicking the downloaded file.

The online snippet converter is a web page for pasting a fragment and getting it back in the other language. That is the fastest path for a small piece of code and the only one that sends your code to a server.

The command line tool is installed with dotnet tool install ICSharpCode.CodeConverter.codeconv --global. The documentation adds a caveat that it still requires VS2026 18.0 or newer installed, which is unusual for a command line tool but follows from the tool being hosted inside the Visual Studio conversion machinery.

The NuGet library, ICSharpCode.CodeConverter, underpins the other free converters found online. If you are building a conversion service or want to drive conversion from your own code, this is the package to reference. Two entry points are named for it: CodeConversion.ConvertDocumentUnhandledAsync and CodeConversion.ConvertProjectUnhandled in the VSIX project, plus ConverterController for a more web oriented API.

All of it is free and open source under the MIT licence.

Why the conversion is asymmetric

This is the fact to understand before you plan anything, and the project states it directly: the VB to C# conversion quality is much higher than the C# to VB conversion quality. The reason given is that the use cases differ considerably, as does the supply and demand of improvements.

The use cases explain it. Visual Basic .NET is described as slowly dying, with support for some project types from .NET 5 but no new features expected according to the .NET Team Blog. So the primary VB to C# use case is moving whole projects, which is a migration with a clear finish line and a lot of code to convert. The C# to VB direction is for helping incorporate snippets from Stack Overflow into an existing VB codebase, or helping someone learn one language from the other. Both are real needs, but the second is episodic and the first is a project.

That asymmetry in effort explains the quality gap, and it means your expectations should differ by direction. A VB to C# conversion of a whole solution is the supported path. A C# to VB conversion is best treated as a snippet-level convenience.

A second limit is project type coverage. Visual Basic has support for some project types from .NET 5, so a solution containing project types that VB does not support is going to hit a wall in the reverse direction.

What Roslyn buys you: selection to solution in one tool

The Visual Studio extension is described as flexible, accurate, safe and integrated, and the accuracy claim has a specific mechanism behind it: full project context through Roslyn is used to get the most accurate conversion.

That is the whole design. Roslyn is the C# compiler platform with a full semantic model, so the converter is not doing text rewriting. It can resolve what a symbol actually is, what a type inference produces, which overload applies and what an implicit conversion would do, and it can therefore produce code that compiles rather than code that merely looks right.

The flexibility claim means the scope can go from a small selection to a whole solution in one go, in either direction. The extension adds the conversion to the context menu, so it works on selected text inside an open file and on projects and solutions.

The safe claim is about execution rather than accuracy: conversion runs entirely locally and your code does not leave your machine. That is true of the extension and of the NuGet library, and it is not true of the online snippet converter, which is worth keeping in mind if the code in question is sensitive.

Progress is reported through the Output window, which shows conversion progress and a summary, so a long solution conversion gives feedback rather than appearing to hang.

Running the website and the extension from source

Building the project needs the.NET Core SDK 10.0, and you open the solution in Visual Studio 2022 or newer with the Community edition being sufficient. Note the numbering: the SDK requirement is.NET 10, while the Visual Studio requirement for the extension download is ideally VS2026 18.0 or newer.

Two startup projects matter. Setting web as the startup project runs the website, and for that you need Node, LTS. Setting Vsix as the startup project runs the Visual Studio extension, and a new instance of Visual Studio opens with the extension installed.

The repository layout supports those two targets explicitly. There is a web/ directory with the ConverterController that the API references, a Vsix/ directory holding the VSIX project with the document and project conversion entry points, a CodeConv/ directory for the command line tool, CodeConverter/ for the shared library, Func/, and Tests/. There are also solution filters, DotNetBuildable.slnf, DotNetPublishable.slnf and Linux.slnf, which is the usual way to give contributors a smaller build on a given platform.

A PowerShell script, IncrementVersion.ps1, sits alongside Get-LatestChangelog.ps1 and Update-NpmPackages.ps1, and there is a nuget.config in the root plus a hooks/ directory.

The command line dropped .NET Framework support in version 10

There is a footnote in the other ways to use the converter section that matters if you maintain older code. If you are converting.NET Framework projects, the command line dropped support for that in version 10, but the Visual Studio extension still supports it.

So the two entry points are not equivalent in coverage. The extension is the broader tool for legacy projects, and the command line is the newer, narrower one.

The release history explains the shape. The listed versions are v10.0.1 from 2026-03-01, v10.0.0 from 2026-02-12, and 8.5.0 from 2022-04-10. The jump from the 8.x line to 10.0 in February 2026 is a major version with a breaking change attached, and the.NET Framework removal is one of them.

There is also a path for people who want the newest code without waiting for a release. The latest CI build is available from the workflow page, marked as potentially less stable, and you uninstall the current version, click a build and download the VSIX file from the bottom of the page.

The project also publishes a wiki with advice on getting the best results, which is where the practical knowledge about what converts cleanly and what does not lives, and a changelog for recent improvements. The repository is not archived and the last push was on 2026-10-22, so the work continues between releases.

Where the converter came from and what it is not

The history section explains the lineage. CodeConverter is a spiritual successor of the code conversion inside SharpDevelop and later part of Refactoring Essentials, and it was separated out to avoid difficulties with different Visual Studio and Roslyn versions.

That last clause is the interesting part and it is a design lesson. Code conversion built on a compiler platform is coupled to that platform's version. Bundling it with a larger IDE meant one project had to track several Visual Studio and Roslyn versions at once. Splitting it into its own repository with its own release cadence is what made it possible to follow the compiler quickly enough to stay accurate.

It is also worth being clear about what this is not. It is not a general purpose transpiler and it does not target other language pairs. The scope is VB.NET and C#, and the scope within that pair is determined by what Roslyn can model and by the effort the maintainer has put into each direction.

It is also not a code formatter or a modernisation tool. It translates between two syntaxes for the same object model. If you want to move a .NET Framework application to modern .NET, this is one step of that work, not the whole of it, and the API surface changes, the project system changes and the deployment model changes alongside the language.

The project encourages contributions, and notes it has already had code contributions from several first time GitHub contributors, which is a reasonable signal that the contribution path is not baroque.

Editorial conclusion

Adopt CodeConverter when you are moving a VB.NET codebase to C#, because the Roslyn based conversion handles whole projects with full semantic context and runs entirely on your machine. Do not adopt it expecting symmetric quality in the other direction, because the project states that VB to C# conversion quality is much higher and that C# to VB is aimed at bringing Stack Overflow snippets into an existing VB codebase. Verify first that you have Visual Studio 2026 18.0 or newer, or the matching .NET Core SDK 10.0 if you are building from source, that you read the wiki advice on getting good results before running a large conversion, and that you keep the converted output under version control so you can review the diff rather than accept a bulk rewrite.

Frequently asked questions

Official sources

1. icsharpcode/CodeConverter on GitHub
2. License: MIT
3. Project website
4. README
5. Releases