VB.NET Module member default Public vs Class default Private — controlling implicit visibility

Short answer

There is no supported language or project-level switch that makes a VB.NET Module default its members to Private, and the compiler emits no diagnostic for an omitted accessibility keyword. The only built-in control is to write an explicit modifier on every Module member. A team must enforce this through convention and code review, not through Option Strict, .editorconfig, or a compiler flag.

Confirmed behavior

In VB.NET, an unmodified member inside a Module is Public; the same omission inside a Class or Structure is Private. This default behavior is stable across VB.NET compiler releases and is unaffected by Option Strict On, target framework, or language version. Partial files do not unify the defaults: an unmodified member in a Partial Module remains Public, while one in a Partial Class remains Private.

Steps for this case

1. Add an explicit accessibility keyword to every Module member. Use Private for helpers, Friend for assembly-scoped APIs, and Public only when exposure is intentional.
2. Update the team coding standard to require the keyword and require reviewers to reject diffs that introduce modifier-less Module members.
3. Optionally run a scoped text search over .vb files to list Module declarations, then manually inspect those files for members that omit Public, Private, Protected, or Friend.

grep -R "\bModule\b" --include="*.vb" src/

InternalsVisibleTo implications

InternalsVisibleTo grants a named friend assembly access to Friend members only; it does not restrict Public members. Because an unmodified Module member is Public, it is visible to any code that can reference the assembly, including code in friend assemblies, without being gated by InternalsVisibleTo. If a helper was moved from a Class to a Module without adding a modifier, its visibility silently widened from Private to Public, bypassing any friend-assembly boundary you intended. Move sensitive helpers to Private or Friend, or keep them in a Class where the default is Private.

Verification

Compile one Module and one Class, each containing a member with no accessibility keyword, then inspect the assembly with reflection, ILDASM, or ILSpy. The Module member should resolve as Public and the Class member as Private. Rebuild with Option Strict On and confirm the compiler emits no diagnostic for the omitted keyword.

Assumptions and missing detail

This assumes the standard Roslyn-based VB.NET compiler. If a future compiler release adds a modifier-default switch or warning, this guidance would need review. One missing detail changes the recommendation: are you enforcing explicit modifiers on new code only, or do you also need to audit already-compiled assemblies for implicitly Public Module members? If an audit is required, add a reflection-based scan of existing binaries as a separate step.