Skip to content

HubClientProxyGenerator doesn't run when using inferred generic type arguments #43510

Description

@albi005

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

SignalR client proxy code isn't generated when using the extension method with auto-inferred type arguments (as suggested by Visual Studio).

Expected Behavior

The proxy code is generated.

Steps To Reproduce

Add Microsoft.AspNetCore.SignalR.Client.SourceGenerator package reference, add this code to a C# file:

using Microsoft.AspNetCore.SignalR.Client;

namespace ConsoleApp4;

internal static class Program
{
    static HubConnection hubConnection = null!;

    static void Main()
    {
        hubConnection = new HubConnectionBuilder().WithUrl("...").Build();
    }

    static void Register(IClient client)
    {
        // \/ Remove type argument here \/
        hubConnection.RegisterClient<IClient>(client);
    }
}

[AttributeUsage(AttributeTargets.Method)]
internal class HubServerProxyAttribute : Attribute
{
}

[AttributeUsage(AttributeTargets.Method)]
internal class HubClientProxyAttribute : Attribute
{
}

internal static partial class MyCustomExtensions
{
    [HubClientProxy]
    public static partial IDisposable RegisterClient<T>(this HubConnection connection, T provider);

    [HubServerProxy]
    public static partial T GetServerProxy<T>(this HubConnection connection);
}

public interface IServerHub
{
    Task SendMessage(string message);
}

public interface IClient
{
    Task ReceiveMessage(string message);
}

public class Client : IClient
{
    public Task ReceiveMessage(string message) => Task.CompletedTask;
}

then remove the generic type argument at line 18.

Activity

  1. BrennanConroy commented on Sep 1, 2022

    @BrennanConroy
    Member

    Looks like the issue is with how we initially filter nodes in the parser:

    internal static bool IsSyntaxTargetForGeneration(SyntaxNode node) => node is MemberAccessExpressionSyntax
    {
    Name: GenericNameSyntax
    {
    Arity: 1
    }
    };

    We're checking if the Generic type is specified which it isn't when you let the inference figure it out.

    This case is handled later on, but it's too late at that point since we've already filtered the method call out:

    else if (memberAccess.Name is not GenericNameSyntax
    && memberAccess.Parent.ChildNodes().FirstOrDefault(x => x is ArgumentListSyntax) is
    ArgumentListSyntax
    { Arguments: { Count: 1 } } als)

  2. added
    bugThis issue describes a behavior which is not expected - a bug.
    on Sep 1, 2022
  3. added this to the .NET 8 Planning milestone on Sep 1, 2022
  4. added
    help wantedUp for grabs. We would accept a PR to help resolve this issue
    on Sep 1, 2022
  5. 94sedighi commented on Dec 13, 2022

    @94sedighi

    I would like to take a look and try to find a solution for this bug

  6. 94sedighi commented on Dec 14, 2022

    @94sedighi

    @albi005 can you please say which version of C# and .NET you are using?
    The partial methods have different restrictions in different C# versions.
    The code you posted to reproduce the Issue doesn't compile in C# 11 and i'm getting the following compiler error:

    Error CS8795 Partial method 'MyCustomExtensions.RegisterClient<T>(HubConnection, T)' must have an implementation part because it has accessibility modifiers.

  7. albi005 commented on Dec 14, 2022

    @albi005
    ContributorAuthor

    I just created a new console app in VS2022 17.5 preview 1 and added the above code to Program.cs.

    The .csproj looks like this:

    <Project Sdk="Microsoft.NET.Sdk">
    
      <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>net7.0</TargetFramework>
        <ImplicitUsings>enable</ImplicitUsings>
        <Nullable>enable</Nullable>
      </PropertyGroup>
    
      <ItemGroup>
        <PackageReference Include="Microsoft.AspNetCore.SignalR.Client" Version="7.0.1" />
        <PackageReference Include="Microsoft.AspNetCore.SignalR.Client.SourceGenerator" Version="7.0.0-preview.7.22376.6" />
      </ItemGroup>
    
    </Project>
  8. added and removed
    help wantedUp for grabs. We would accept a PR to help resolve this issue
    on Oct 28, 2023
  9. added
    help wantedUp for grabs. We would accept a PR to help resolve this issue
    and removed on Jan 7, 2026
  10. added theissue type on May 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area-signalrIncludes: SignalR clients and serversbugThis issue describes a behavior which is not expected - a bug.help wantedUp for grabs. We would accept a PR to help resolve this issue

Type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions