ReadAsync ambiguous when called from VB.NET (multiple member kinds in ClientSession)

[togabrennan]

📝 Description

When calling ClientSession.ReadAsync from VB.NET, the compiler raises the following error:

'ReadAsync' is ambiguous because multiple kinds of members with this name exist in class
'ClientSession(Of Key, Value, Input, Output, Context, Functions As IFunctions(Of Key, Value, Input, Output, Context))'.

This happens because VB.NET cannot disambiguate between different ReadAsync members — for example, the instance method(s) and the extension method(s) exposed in the same namespace.
In C#, the same call compiles fine, but VB’s overload resolution treats these as multiple “kinds” of members, so it cannot choose one.

---

🧪 Reproduction Steps

1. Create a VB.NET project targeting .NET 6 or newer.
2. Add a reference to the FASTER NuGet package (latest version).
3. Write a simple session call like:

Imports FASTER.core

Dim store = New FasterKV(Of Integer, String)(...)
Dim session = store.NewSession(Of MyFunctions)(...)

Dim result = Await session.ReadAsync(1, Nothing, Nothing)

4. Compile.

❗ Expected Result

VB.NET should resolve to the instance ReadAsync method on ClientSession (just like C# does).

💥 Actual Result

BC31429: 'ReadAsync' is ambiguous because multiple kinds of members with this name exist...

⚙️ Environment

FASTER version: (e.g., 3.5.12)
.NET version: 6.0 / 7.0 / 8.0
Language: VB.NET
IDE: Visual Studio 2022

🧭 Analysis

FASTER exposes both instance and extension methods named ReadAsync with overlapping signatures.
VB.NET treats extension methods as separate “kinds” and reports ambiguity when both are visible.
This does not affect C#, which picks the instance method correctly.

💡 Possible Solutions

Rename or hide one of the ReadAsync extensions to avoid the name collision.
Add a [EditorBrowsable(EditorBrowsableState.Never)] or [Browsable(false)] attribute to the extension overloads.
Alternatively, provide a simple alias method for VB consumers (e.g., ReadAsyncValue).

🗒️ Notes

While this ambiguity does not affect C#, it blocks VB.NET consumers from using ReadAsync directly.
The issue can be reproduced in a minimal VB.NET project with the default ClientSession types and parameters.