Option Strict Off vs On for Late‑Bound COM Members in VB.NET

Direct Answer

Enable Option Strict On project‑wide, reference the Office Primary Interop Assemblies (PIAs) via NuGet with EmbedInteropTypes=true, and isolate any unavoidable late‑bound calls in a single file/module that uses Option Strict Off or explicit reflection wrappers. This gives compile‑time safety on both .NET Framework 4.8 and .NET 6+ while keeping the codebase maintainable.

Why This Works (Likely Explanation)

• Compile‑time checking catches missing members early, preventing the runtime failures that are common with Option Strict Off.
• Embedded interop types (NoPIA) work identically on .NET Framework 4.5+ and .NET 6+, so you don’t need separate PIA installations on each machine.
• Late‑binding resolution differs between the two runtimes (VB’s built‑in binder vs. the DLR/IDispatch). Keeping the bulk of the code early‑bound avoids the fragility that appears when the same Option Strict Off code runs on both platforms.

Confirmed Facts (From Compiler Behavior)

• Option Strict On forces early binding; the compiler will error on any member not described in the referenced interop assemblies.
• EmbedInteropTypes embeds only the types you actually use, reducing deployment size and eliminating version‑specific PIA dependencies.
• Late‑bound calls (e.g., CallByName, My.Computer, dynamic dispatch) compile only when Option Strict Off is in effect for that file/module.

Steps to Migrate Safely

1. Set Option Strict On in the project properties (or add Option Strict On at the top of every source file).
2. Add the appropriate Microsoft.Office.Interop.* NuGet packages. Verify the project file contains <EmbedInteropTypes>true</EmbedInteropTypes> for each reference.
3. Build the project. Each error points to a member that is not present in the PIAs.
4. For every error, decide:
   • If the member exists in the PIA, fix the code to use the strongly‑typed API.
   • If the member is truly missing (e.g., a custom add‑in interface), move that call into a dedicated module/file and add Option Strict Off only there, or wrap the call with explicit reflection/DynamicObject.
5. Run the full Office automation test suite on .NET Framework 4.8 and on .NET 6+ to confirm identical runtime behavior.

One Diagnostic Detail That Could Change the Recommendation

Does your code call COM members that are not exposed in the Office PIAs (for example, dynamic dispatch to third‑party add‑ins or version‑specific interfaces)? If the answer is yes, you will need the isolated Option Strict Off shim described in step 4; otherwise a pure Option Strict On build is sufficient.

Verification Checklist

• Project compiles with zero late‑binding errors under Option Strict On.
• EmbedInteropTypes is true for all Office interop references.
• Automated tests pass on both .NET Framework 4.8 and .NET 6+.
• Any Option Strict Off files are limited to a single, well‑named module (e.g., ComLateBoundShims.vb).