microsoft / microsoft/FASTER

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

Open
#949 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C#
Stars
6.6k
Forks
595
PR merge metrics
No merged PRs in 30d

Description

📝 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)
  1. 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the call in a minimal VB.NET project targeting .NET 6 or newer, then inspect the ClientSession ReadAsync instance and extension members exposed by the FASTER package. Done means the sample compiles and VB.NET resolves the intended instance method without ambiguity; the issue does not identify a source file or test to update.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
api, developer-experience
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.