Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Trimming] SignalR #41704

Open
1 task done
JamesNK opened this issue May 17, 2022 · 8 comments
Open
1 task done

[Trimming] SignalR #41704

JamesNK opened this issue May 17, 2022 · 8 comments
Assignees
Labels
area-signalr Includes: SignalR clients and servers linker-friendliness Tracking linker friendliness
Milestone

Comments

@JamesNK
Copy link
Member

JamesNK commented May 17, 2022

Is there an existing issue for this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

SignalR should run in a trimmed app.

Describe the solution you'd like

Shipping projects under https://github.com/dotnet/aspnetcore/tree/main/src/SignalR need to add support for trimming.

See https://github.com/dotnet/aspnetcore/blob/main/docs/Trimming.md for instructions

Additional context

No response

@JamesNK JamesNK added area-signalr Includes: SignalR clients and servers linker-friendliness Tracking linker friendliness labels May 17, 2022
@halter73 halter73 added this to the .NET 7 Planning milestone May 17, 2022
@ghost
Copy link

ghost commented May 17, 2022

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

@ghost
Copy link

ghost commented Sep 12, 2022

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

@stealthin
Copy link

Hey there!
We really need this happening, do you have an ETA?

@davidfowl
Copy link
Member

davidfowl commented Nov 24, 2023

.NET ships yearly. We just finished 8, so 9 is next year. This will be considered in planning (which we haven’t done yet)

@stealthin
Copy link

stealthin commented Nov 24, 2023

Thank you for your answer @davidfowl. I guess this won't weight much, but if it could get prioritized that'll be awesome. There isn't any solid alternative to SignalR, and this NativeAOT compatiblity is our single blocker as of today.

@davidfowl
Copy link
Member

You can use raw WebSockets as an alternative. NativeAOT incompatibility is going to everywhere 😄 that didn't plan for it.

@BrennanConroy BrennanConroy modified the milestones: .NET 8 Planning, Backlog Mar 2, 2024
@eerhardt
Copy link
Member

eerhardt commented Jun 25, 2024

#56079 and #56460 make the core of SignalR client and server, along with the JsonProtocol trimming and AOT compatible with the following known limitations/drawbacks:

  • Only the JSON protocol is currently supported
    • Need to use the Source Generator - both client and server. This follows the same approach as Minimal APIs.
  • SignalR Server parameters of type IAsyncEnumerable<T> and ChannelReader<T> where T is a ValueType are not supported
    • Will get runtime exceptions at startup during F5 time and in published app
    • The SignalR client supports passing in IAsyncEnumerable<T> and ChannelReader<T> parameters where T is a ValueType in native AOT. It is only the server where this scenario can't be supported.
    • Return types of IAsyncEnumerable<T> and ChannelReader<T> where T is a ValueType are supported in both the client and the server
    • See SignalR: Using IAsyncEnumerable<T> and ChannelReader<T> with ValueTypes in native AOT #56179 (comment) for more information.
  • Custom awaitables and certain F# patterns on the server are not supported in trimming or AOT
    • There is a Feature switch (Microsoft.AspNetCore.SignalR.Hub.IsCustomAwaitableSupported AppContext switch and SignalRCustomAwaitableSupport MSBuild property) that is disabled by default in trimmed and AOT'd apps
  • Client proxy generation is not supported in PublishAot - will get warnings at build-time
    • Works with PublishTrimmed with no warnings

@eerhardt
Copy link
Member

eerhardt commented Jul 8, 2024

The core of SignalR server and client is trimming and native AOT compatible as of .NET 9 Preview 7. Along with the Json protocol.

Leaving this issue open to track also making the following trim and native AOT compatible:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-signalr Includes: SignalR clients and servers linker-friendliness Tracking linker friendliness
Projects
None yet
Development

No branches or pull requests

6 participants