Option Strict On in Visual Basic .NET: Catch Type Mismatches at Build Time

The problem: builds pass, runtime fails

A Visual Basic .NET application can build cleanly and still crash in production with an InvalidCastException. The cause is often an implicit narrowing conversion, such as assigning a Double value to an Integer variable, or a late-bound call on an Object variable whose type is only known at runtime. The useful takeaway is that Option Strict On moves these failures from runtime to compile time, so the build breaks before users encounter them.

What Option Strict controls

Option Strict is a Visual Basic .NET compiler setting. When it is Off, the compiler permits implicit narrowing conversions, such as assigning a floating-point value to an integer variable without an explicit cast. It also permits late binding, where members of an Object variable are resolved at runtime rather than checked against a declared type.

When Option Strict is On, both behaviors are disallowed. You must use an explicit conversion function such as CInt, CDbl, or Convert.ToInt32, and you must declare variables with specific types instead of relying on Object member access. A narrowing conversion is one that can lose data or fail, such as Double to Integer. Late binding means calling a member on an Object whose type is not known until the program runs.

Where to enable it

You can set Option Strict in two places:

• Per file: add Option Strict On at the top of a source file, before any other code.
• Project level: open the project designer in Visual Studio, choose the Compile tab, and set Option Strict to On.

Project level is usually the better default for new code. File level is useful when you need to enable the setting incrementally in a legacy project. Visual Studio VB.NET templates often default Option Strict to Off to ease migration from older Visual Basic versions, so the setting is not always On by default.

In the project file, the setting appears as an XML element. You can verify it by opening YourProject.vbproj in a text editor and looking for the Option Strict element under the Visual Basic configuration:

<PropertyGroup>
  <OptionStrict>On</OptionStrict>
</PropertyGroup>

Edit the project file only with source-control awareness. A manual XML edit changes build state and should be reviewed like any other build configuration change.

Worked example: narrowing conversion

Consider this module with Option Strict Off:

Option Strict Off

Module Example
    Sub Main()
        Dim price As Double = 19.99
        Dim wholePrice As Integer = price ' compiles, but loses the fractional part
        Console.WriteLine(wholePrice)
    End Sub
End Module

With Option Strict On, that assignment produces a compiler error instead of building successfully. The fix is an explicit conversion:

Option Strict On

Module Example
    Sub Main()
        Dim price As Double = 19.99
        Dim wholePrice As Integer = CInt(price) ' explicit narrowing conversion
        Console.WriteLine(wholePrice)
    End Sub
End Module

To verify the behavior yourself, create a console application in Visual Studio, add Option Strict On, attempt the implicit assignment, and build. The build should fail with a narrowing-conversion error. Change the line to use CInt and rebuild; it should succeed. Do not assume the exact error text, since it can vary by Visual Studio and .NET version.

Limitations and trade-offs

Enabling Option Strict On does not make a program type-safe by itself. It still permits explicit invalid casts, and it does not prevent null reference exceptions. It also does not catch logic errors where the correct type is used with the wrong value.

In a legacy project, switching the project-level setting to On can generate many compile errors at once. Every error must be fixed before the project builds, which can block delivery if the team is not prepared for the work. A safer migration path is to enable Option Strict On file by file, fixing errors in each file before moving to the next, or to enable it only for new files while leaving existing files at Off until they are refactored.

Mixed settings across files can make the codebase harder to reason about, so document which files use which setting and plan to converge on On over time.

Practical check and closing

After changing the setting, build the solution in Visual Studio and review the Error List. If you see narrowing-conversion or late-binding errors, those are exactly the failures Option Strict is designed to surface early. Fix them with explicit conversions or typed declarations, then rebuild.

For new Visual Basic .NET projects, enable Option Strict On at project creation. For existing projects, treat it as an engineering decision: the benefit is earlier failure detection, and the cost is upfront refactoring work. Start with one file, confirm the build behavior, and expand from there.