Visual Basic.CodeCompared.To/C#

Both lines call the same Console.WriteLine from the same .NET base class library; only the packaging differs. C# still has Main — the compiler writes one for you and puts these statements inside it — so nothing was taken away, it was made implicit. The semicolon is not optional: C# ends every statement with one rather than using the end of the line.

Statements written straight into a file are called top-level statements, and only one file in a project may have them. Everything you would have put in Module Program goes here directly, and any classes or records you need are declared after the statements, at the bottom of the file. This is why every C# example on this page starts with executable code and defines its types last — the compiler requires that order.

The $"..." form and its format specifiers (D5, F2, N0, P1) came from the same compiler team and work the same way. If you are arriving from VB6 or VBA rather than VB.NET, this replaces the Format$() and &-chaining habit entirely, in both languages.

Visual Basic capitalizes True and False; C# writes true and false, and will not accept the capitalized forms. That is not a style preference — C# is case-sensitive, so True is simply an unknown identifier. The same applies to Nothing, which becomes null.

The condition needs parentheses in C# and no Then; ElseIf becomes two words, else if. A block of exactly one statement may drop its braces entirely (if (x) DoThing();), which has no Visual Basic parallel except the single-line If ... Then ... form. Most C# codebases keep the braces anyway.

C# gains a genuine block comment, /* ... */, which Visual Basic has never had; that is why long commented-out passages in Visual Basic are a column of apostrophes. Documentation comments survive the trip: ''' becomes ///, and the XML tags inside (<summary>, <param>, <returns>) are identical, because both compilers emit the same documentation file.

Visual Basic identifiers are case-insensitive — the editor even rewrites your casing to match the declaration — so customerName and CustomerName are one name. In C# they are two names, and nothing warns you. The convention that saves you is the one the .NET libraries already follow: camelCase for locals and parameters, PascalCase for types, methods, properties and constants. Follow it and the two never collide.

C# ends a statement at the semicolon, not at the end of the line, so a statement may be broken across as many lines as you like with no continuation character at all. Visual Basic has drifted the same way — since VB 2010 most line breaks are inferred and the _ is only needed in the remaining awkward spots, as after an opening parenthesis in the example above. In C# there is no awkward spot.

Read Dim count As Integer right to left and you have C#'s int count. The literal suffixes change case: D for decimal becomes m (for "money", since d was taken by double), F becomes f, L stays L. There is no Option Explicit switch to forget — C# has never allowed an undeclared variable.

Both are compile-time inference, not dynamic typing: count is an int forever and assigning a string to it is a compile error. The difference is that C# has no Option Infer to turn off, and no Option Strict either — its inference is always on and its strictness is never negotiable. Note also that the generic type argument moves from (Of String) to <string>.

Integer→int, Long→long, Short→short, Single→float, Double→double, Boolean→bool, String→string, Object→object. Both sets are aliases for the same .NET types (System.Int32 and the rest), so nothing changes at runtime. The one that catches people is Char: Visual Basic writes "A"c with a suffix, C# uses single quotes, and single quotes in C# are never a string.

Const stays const and must be a compile-time literal in both. ReadOnly becomes readonly, and is what you need for anything computed — a DateTime, a List, anything built with New. Note that a C# const is implicitly static, so it lives on the type rather than the instance, exactly as a Const in a Module does.

Nothing becomes null, and the two are not quite the same idea. Assigning Nothing to an Integer in Visual Basic quietly stores zero — Nothing means "the default value for this type". C# refuses: int x = null; is a compile error, and only int? can hold null. The ?? operator, read "or else use", is C#'s equivalent of the two-argument If(value, fallback).

CInt, CDbl, CStr and friends split three ways in C#. Parsing text uses int.Parse / int.TryParse; a widening conversion such as int to double needs nothing at all; a narrowing or unboxing conversion uses a cast in parentheses, (int)boxed, which is DirectCast. TryCast — a cast that yields Nothing instead of throwing — is C#'s as operator, and works only on reference and nullable types.

Comparison is == and inequality is != rather than <>. The classic C trap — writing if (x = 5) and assigning by accident — cannot happen here, because a C# if requires a bool and an assignment of an int yields an int, so the compiler rejects it. The same rule means if (count) is an error too: there is no truthiness in C#, and no 0 = False convention.

AndAlso→&&, OrElse→||, And→&, Or→|, Xor→^, Not→!. The mapping is exact, including the trap: And and & both evaluate the right-hand side even when the left has already settled the answer, which is why the second If prints "(checked)". C# convention is to reach for && and || by default and treat & / | as bitwise operators, which is what they mostly are.

This is the single most dangerous line-for-line translation on the page. Visual Basic's / always produces a floating-point result and \ is the integer one. C# has no \: 17 / 5 between two ints truncates to 3, and you get the fractional answer only by making an operand floating-point — 17 / 5.0, or (double)a / b. A Visual Basic / copied straight across silently starts truncating. Mod becomes %.

C# has no exponent operator; Math.Pow is the answer, and it takes and returns double just as ^ does. Do not reach for ^ out of habit — it compiles, but it is the bitwise exclusive-or operator, so 7 ^ 2 quietly evaluates to 5 rather than 49. That is a wrong answer with no error message, which makes it worth memorizing now.

C# concatenates with +. Visual Basic has both, and the reason it prefers & is that + is ambiguous there — with Option Strict Off, "1" + 2 could add rather than join. C#'s + has no such ambiguity: if either operand is a string, the other is converted with ToString() and the result is a string. & in C# is bitwise-and, so using it by mistake will not compile against strings.

Three-argument If(condition, whenTrue, whenFalse) becomes the conditional operator condition ? whenTrue : whenFalse — read the ? as "then" and the : as "otherwise". Two-argument If(value, fallback) becomes ??. Both C# forms short-circuit exactly as the If() function does, which is what made IIf() — the VB6 version that evaluated everything — worth abandoning.

Dim builder As New StringBuilder() and var builder = new StringBuilder() allocate the identical object. Note that C# has no As New shorthand: new is always an expression on the right of the =. The reason to use StringBuilder is the same in both languages — strings are immutable, so text = text & more inside a loop allocates a fresh string every pass.

In Visual Basic a string literal has exactly one escape, the doubled quote, and a backslash is just a backslash — which is why Windows paths are so comfortable there. C# treats \ as an escape character, so "C:\reports" either means something else or fails to compile. Two forms rescue you: @"..." switches escaping off, and the raw literal """...""" switches it off and spans lines, stripping the common indentation of the closing delimiter. Both accept a $ prefix for interpolation.

Because both languages call into System.String, Trim, ToUpper, Contains, Replace and Substring need no translation at all. What has no C# counterpart is the second family Visual Basic keeps for compatibility — Mid, Left, Right, Len, InStr, UCase. Those come from Microsoft.VisualBasic and are 1-based, which is exactly why they are worth dropping: Mid(text, 1, 6) and text.Substring(0, 6) return the same thing from different starting points. C# adds a range operator, [..6], meaning "from the start up to index 6".

By default both compare character by character, so "Report" and "report" are different. The difference is that Visual Basic has a file-level switch, Option Compare Text, which silently makes every = on strings in that file case-insensitive. C# has nothing of the kind and never will: == on strings is always an ordinal value comparison. If you rely on Option Compare Text anywhere, that behavior has to be written out explicitly with StringComparison.OrdinalIgnoreCase when you port the code.

Indexing moves from parentheses to square brackets, which also removes a genuine ambiguity — in Visual Basic names(1) could be an array element or a method call, and only the compiler knows which. The number is the real trap: Dim scores(4) declares five slots because it names the highest index, while new int[5] names the count. Both are zero-based and both have .Length, so Dim x(n) becomes new[n + 1]. VB6 programmers should also note that Option Base 1 does not exist in .NET at all.

List(Of String) becomes List<string> — angle brackets instead of (Of ...), and this holds for every generic type: Dictionary(Of K, V) → Dictionary<K, V>, IEnumerable(Of T) → IEnumerable<T>. The From { ... } initializer loses the From. If you are used to VB6's Collection object, note it is 1-based and untyped; List<T> is neither.

Visual Basic's nested-brace initializer {{key, value}, ...} has a C# equivalent, but the indexer form ["Ada"] = 36 shown here reads better and is what most C# code uses. The real convenience is out int found: C# lets you declare the output variable inside the call, so the two-line dance of declaring it first disappears. Note var entry where Visual Basic spelled out KeyValuePair(Of String, Integer) — the type is inferred, not dynamic.

A rectangular array is Dim grid(,) As Integer in one language and int[,] grid in the other; both index with a single pair of brackets holding two numbers. A jagged array — rows of independent length — is ()() and [][], indexed one bracket at a time. The C# form reads left to right (int[][] is "array of int arrays"), whereas the Visual Basic form puts the element type after the parentheses, which is why it looks backwards at first.

Every C# case body must end with break (or return, or goto case) — C# forbids silently falling through to the next branch, so the compiler rejects a missing break rather than doing what Visual Basic already does automatically. Sharing one body between two values is done by stacking bare labels, which is the one legal kind of fall-through. Case Is > 100 becomes a relational pattern case > 100, and Case 4 To 6 becomes case >= 4 and <= 6.

The switch expression puts the value first and the keyword second (code switch), replaces case/:/break with => and a comma, and uses _ for the default arm. Because it is an expression it always produces a value, and the compiler warns when the arms do not cover every possibility. Visual Basic has no equivalent — a Select Case is always a statement, which is why the anchor column needs a whole Function to do the same job.

A C# condition must be a bool. There is no implicit "zero is false, non-zero is true" and no implicit "empty string is false"; if (count) does not compile. The habit worth carrying over is spelling out what you actually mean — count == 0, name is null, string.IsNullOrEmpty(name). Note is null rather than == null: both work, but is cannot be redefined by an overloaded operator, so it is the safer of the two.

C#'s for is "initializer; condition; step", separated by semicolons — you state the ending condition rather than an ending value, which is why the inclusive To 5 becomes <= 5. Getting < and <= the wrong way round is the classic off-by-one here, and it is worth pausing on every time. Step -2 becomes the step clause countdown -= 2, and the loop variable is scoped to the loop exactly as index As Integer is.

For Each x As T In items ... Next becomes foreach (T x in items) { ... } — one word, no Next. Neither language has a built-in index in its for-each, but C# can pair value and position with Select((value, position) => (value, position)) and unpack both in the loop header. The plain counted loop shown in the anchor column is still perfectly good C# too; this is an option, not a replacement.

While ... End While becomes while (...) { }. The Do ... Loop family collapses: Do While c, Do Until c, Loop While c and Loop Until c all become either while or do ... while, and since C# has no Until, the condition has to be inverted — Loop Until attempt >= 2 becomes while (attempt < 2). Note the semicolon after the closing while of a do loop; it is the one place a brace is followed by one.

Exit For, Exit While and Exit Do all become plain break; Continue For and friends become plain continue. Both always act on the innermost enclosing loop, which is a real loss of clarity in nested loops — Visual Basic at least named the construct. C# has goto with a label for the rare case where you need to leave two levels at once, though extracting the loop into a method and using return is the usual answer. Exit Sub and Exit Function both become return.

The return type moves to the front, replacing both keywords: Sub becomes void and Function ... As Integer becomes int. Return becomes return and is required — C# has nothing like assigning to the function's own name, the VB6 style that Function Add ... Add = 5 allowed. Calling is simpler too: parentheses are always required and always allowed, so the old rule about omitting them when calling a Sub is gone.

ByRef becomes ref when the value goes in and comes back, and out when it is purely an output — and out obliges the method to assign it on every path, which is why TryHalve sets result = 0 first. The bigger change is at the call site: C# requires ref or out on the argument too, so you can never be surprised by a method that reassigns your variable. ByVal has no keyword because it is the only default.

The Optional keyword disappears — a default value is enough to make a parameter optional, and optional parameters must still come last. A named argument uses name: with a space rather than name:=. Note the method body here: => introduces an expression-bodied member, a one-line method with no braces and no return, which reads much like Visual Basic's single-line Function shorthand.

ParamArray values() As Integer becomes params int[] values. In both languages it must be the last parameter, there can be only one, and the caller may pass either loose arguments or a ready-made array. This is what Console.WriteLine's many overloads and String.Format have always used underneath.

Public Sub New(...) becomes a method with no return type whose name is exactly the class name. Me becomes this where you need it. Notice the C# class sits below the executable statements: in a file using top-level statements, type declarations must come after them. Access modifiers are the same words in lower case, and a C# class member with no modifier at all is private, whereas an unmarked Visual Basic member is Public — so leaving the keyword off changes the meaning.

Public Property Label As String becomes public string Label { get; set; }, and the full Get/Set blocks become get and set accessors, which can be one-liners with =>. The implicit value parameter exists in both. A ReadOnly Property with only a Get collapses all the way to a single expression-bodied member, as Fahrenheit shows. The object initializer With {.Celsius = 100.0} becomes { Celsius = 100.0 } — no With, no leading dots.

Shared becomes static, with the same meaning: one copy on the type rather than one per instance. What has no direct counterpart is the Module itself, which is really a class where everything is Shared and whose members can be called without naming it. The C# equivalent is a static class, but its members always need the type name in front — Counter.Total, never a bare Total. A using static Counter; directive restores the bare form when you want it.

Inherits Animal becomes : Animal on the class header — the same colon C# uses for interfaces, so a class list reads "base class first, then interfaces". Overridable becomes virtual, Overrides becomes override, and MyBase becomes base. Calling the base constructor moves from a statement inside the body (MyBase.New(name)) to a clause on the header (: base(name)). Both languages agree on the important part: a method is not overridable unless it says so.

MustInherit becomes abstract on the class, MustOverride becomes abstract on the member, and NotInheritable becomes sealed. NotOverridable — sealing a single override so no further subclass can change it — is also sealed, written as sealed override. C# reuses one word where Visual Basic used four, which is terser but means you read the position to know which meaning applies.

Visual Basic attaches Implements IGreeter.Greet to each member individually, so the method may be called anything you like — SayHello here satisfies Greet. C# matches by signature: a public method with the right name and parameters implements the interface member automatically, and there is no clause to say otherwise. When two interfaces demand the same signature and you need different bodies, C# offers explicit implementation — string IGreeter.Greet(string name) — which is the closest equivalent, and such a member is callable only through the interface.

Structure ... End Structure becomes struct { }, with the same semantics — assignment copies the whole value rather than sharing a reference, and equality compares fields. C# adds readonly struct, which promises the compiler that no member mutates the value and lets it skip defensive copies. Overrides becomes override here as with any inherited method, and Me.X becomes plain X where there is no name collision.

A record declares the properties, the constructor, value-based Equals, GetHashCode, ==, and a readable ToString in one line. It also gets a with expression, which copies the value and changes named parts — an idea Visual Basic has no equivalent for, and unrelated to the With block. Visual Basic cannot declare a record; when you need this shape there, you write it out, which is what the anchor column shows. This is one of the clearest reasons a Visual Basic codebase gains from moving.

The tuple type (Smallest As Integer, Largest As Integer) becomes (int Smallest, int Largest), and both let you name the parts so the caller does not have to remember an order. Deconstruction is C#-only: var (low, high) = ... pulls the parts into separate variables in one statement, which is what makes returning a tuple pleasant rather than merely possible. Visual Basic has to name the tuple and read its fields, as the anchor column does.

TypeOf value Is Integer becomes value is int, and adding a name — value is int number — both tests and converts in one go, with number in scope for the rest of the branch. That name is why the cast on the next line vanishes. Note that C# is is a type test, whereas Visual Basic's bare Is compares references; the gotchas section returns to this, because it is the one keyword whose meaning genuinely changes.

Patterns compose: int and < 0 combines a type pattern with a relational one, and string { Length: 0 } is a property pattern that matches a string whose Length is zero. Arms are tried top to bottom, so the narrow cases come first. Visual Basic has no pattern matching at all — its Select Case compares values only — so any code shaped like this is a candidate for real simplification when it moves.

A property pattern names members inside braces — { Country: "US", Total: > 100 } — and each part may itself be any pattern, including another property pattern for a nested object. Compared with the chain of If statements it replaces, the win is that the conditions line up in a column, so a missing combination is visible rather than buried. The compiler also warns if an arm is unreachable because an earlier one already covers it.

Catch name As TypeName becomes catch (TypeName name) — the same reordering as a variable declaration. Order still matters: the most specific exception type first, or the broad Exception catch swallows everything below it. Finally runs on every path in both. What does not come across is On Error Resume Next and On Error GoTo: C# has no unstructured error handling at all, and VB6 or VBA code built on it has to be rewritten as try blocks rather than translated.

When becomes when, and the condition gains parentheses. The point of a filter rather than an if inside the catch is that a filter runs before the stack unwinds: if it returns false the exception continues to propagate with its original stack intact, which is a real advantage when debugging. Note that C# lets you omit the variable name entirely when you do not need it, as the first catch does.

Throw New becomes throw new, and the custom type inherits from Exception with : Exception. Public ReadOnly Property Shortfall with no setter becomes public decimal Shortfall { get; } — a get-only auto-property, settable only from the constructor. Both languages let a bare Throw / throw inside a catch rethrow the current exception without resetting its stack trace, which is what you want when you are logging and passing it on.

Using ... End Using becomes using (...) { }, and both guarantee Dispose is called even when an exception escapes. C# adds the using declaration — using var reader = ... with no block at all — which disposes at the end of the enclosing scope instead, and is the form most new C# code uses when a method holds one resource for its whole body. The explicit Dispose() here is only so the file can be deleted on the next line.

Function(value) value * 2 becomes value => value * 2; a multi-statement lambda uses braces instead of Sub ... End Sub. C# does not distinguish the two forms — whether a lambda returns a value is decided by its body and the delegate type it is assigned to. Func(Of Integer, Integer) becomes Func<int, int> and Action(Of String) becomes Action<string>; in both languages the last type argument of Func is the return type, and Action returns nothing.

Once the lambdas are converted, LINQ method chains translate mechanically, because they are the same extension methods on IEnumerable<T>. One small formatting note: Visual Basic puts the dot at the end of the line to continue the chain, C# puts it at the start of the next line. Both are conventions, but every C# codebase you meet will use the leading dot.

The keywords lower-case and Order By becomes one word, orderby. C#'s query syntax is the smaller of the two: Visual Basic also has Aggregate, Distinct, Skip, Take and Group By ... Into as query keywords, where C# has only from, where, select, orderby, join, let, group ... by and into. Anything else is written as a method call on the end of the query, which is why most C# code uses method syntax throughout rather than mixing the two.

GroupBy returns a sequence of groups, each of which has a Key and is itself a sequence you can iterate or aggregate. The only Visual Basic-specific detail that changes is indexing a string: word(0) becomes word[0], because square brackets index and parentheses call. Every aggregate you know — Count, Sum, Average, Min, Max, Aggregate — is the same method in both.

Async Function ... As Task(Of String) becomes async Task<string>, and Await becomes await. An Async Sub becomes async void and is just as bad an idea in both — its exceptions cannot be caught by the caller. The genuine convenience is that C# allows await directly in top-level statements: the compiler generates an async Main for you, so the GetAwaiter().GetResult() bridge in the anchor column is not needed.

Iterator Function ... As IEnumerable(Of Integer) becomes plain IEnumerable<int> and Yield x becomes yield return x. Both are lazy: nothing runs until the caller asks for the first item, and execution suspends at each yield. Exit Function in an iterator becomes yield break. The C# column also slips in tuple assignment — (previous, current) = (current, previous + current) — which swaps two variables without a temporary, something Visual Basic has no syntax for.

Visual Basic marks an extension method with the <Extension()> attribute and needs Imports System.Runtime.CompilerServices for it. C# marks it by putting this on the first parameter, inside a static class, with no attribute and no import. Both compile to the same thing — an ordinary static method the compiler lets you call as though it were an instance method. Attributes in general translate by swapping the brackets: <Obsolete("...")> becomes [Obsolete("...")].

Imports becomes using, and an aliased import keeps the same Name = FullType shape. The wrinkle: a Visual Basic project has project-level imports set in the project properties, so System is often already available without a line in the file. C# has the same idea under the name implicit usings, on by default in new projects, which is why the examples on this page never write using System;. Namespaces also gain a file-scoped form — namespace Reporting; on one line, with no braces, indenting nothing.

In Visual Basic you may type Total where you declared total and the editor quietly corrects you. In C# nothing corrects you — either the name is undefined and you get an error, or, much worse, a name with that exact casing exists elsewhere and your code compiles while referring to the wrong thing. The habit that removes the risk is the .NET naming convention: locals and parameters camelCase, everything public PascalCase. Follow it and two names never differ by case alone.

Visual Basic's Is compares references and TypeOf x Is T asks about the type. C# reverses it: is is the type test, and reference comparison is ReferenceEquals(a, b) or (object)a == (object)b. So left Is right translated literally to left is right does not mean the same thing — and against a type name it will happily compile. IsNot has no C# keyword at all; negate with !. The one place is keeps the Visual Basic meaning is x is null, which is a null check in both.

Dim slots(5) declares indices 0 through 5, which is six elements, because the number is the upper bound. new int[5] declares five, because the number is the count. Translating one to the other means adding or subtracting one, every time. UBound(array) has no C# equivalent and becomes array.Length - 1; LBound is always zero and simply disappears. Anyone bringing habits from VB6 should also note that Option Base 1 and ReDim Preserve have no counterparts here at all — resizing means Array.Resize or, far better, a List<T>.

C# has no With block. Three things replace it depending on why you were using it. For setting several properties on a new object, use an object initializer: new Order { Total = 5m, Country = "US" }. For calling several methods in a row, use method chaining where the type supports it, as StringBuilder does above. Otherwise, assign the object to a short local and repeat the name — which is what the compiler was doing for you anyway. Note that C#'s with keyword is unrelated: it copies a record, as the records section showed.

The My namespace — My.Computer, My.Application, My.Settings, My.Resources, My.Forms — is generated by the Visual Basic compiler and has no C# counterpart. Everything it offers is a shortcut to something in the base class library, so porting means finding the real API underneath: My.Computer.FileSystem is System.IO.File and Directory, My.Computer.Name is Environment.MachineName, My.Settings is the generated Settings class, My.Application.Info is Assembly.GetEntryAssembly(). The same is true of the Microsoft.VisualBasic functions — MsgBox, InputBox, IsNumeric, Val, Now.