-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Default new Razor Components project loads empty page, then get Failed to reconnect to the server. [Retry?]
message.
#8520
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
Comments
Saw this in the console log, don't know if relevant:
But if it's not relevant, there still definitely shouldn't be some exception there. |
This is related to ref-assemblies. Ref assemblies don't include non-public members, and components currently recommend using non-public members for component properties. {
"Kind": "Components.Component",
"Name": "Microsoft.AspNetCore.Components.Routing.Router",
"AssemblyName": "Microsoft.AspNetCore.Components",
"Documentation": null,
"TagOutputHint": null,
"TagMatchingRules": [
{
"TagName": "Router",
"ParentTag": null,
"TagStructure": 0,
"Attributes": [],
"Diagnostics": []
}
],
"BoundAttributes": [], // There should be something here!
"AllowedChildTags": [],
"Diagnostics": [],
"Metadata": {
"Runtime.Name": "Components.IComponent",
"Common.TypeName": "Microsoft.AspNetCore.Components.Routing.Router"
}
}, The parameters of the component are not being discovered, and the compiler behaves differently depending on the declared type of a parameter (tag helpers). Since the parameters aren't being found, all parameters are treated like string-likes. So This means that recent builds are complete blocked from using any components we ship in the box. |
@SteveSandersonMS - lets discuss this this week. |
This resolves the issue blocking use of component parameters from our ref assemblies. Making properties public with private get is our recommended guidance for wanting documentation to work in the IDE, and it will be required when you ship ref assemblies - since ref assemblies only contain public members.
This resolves the issue blocking use of component parameters from our ref assemblies. Making properties public with private get is our recommended guidance for wanting documentation to work in the IDE. We also now need to manually generate the ref-assembly types for these so they will show up for tooling with setters. I've logged an issue to track whether we want to keep this long term, it seems like a suitable workaround for now.
This resolves the issue blocking use of component parameters from our ref assemblies. Making properties public with private get is our recommended guidance for wanting documentation to work in the IDE. We also now need to manually generate the ref-assembly types for these so they will show up for tooling with setters. I've logged an issue to track whether we want to keep this long term, it seems like a suitable workaround for now.
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
Default new Razor Components project loads empty page, then eventually times out with
Failed to reconnect to the server. [Retry?]
message.To Reproduce
Steps to reproduce the behavior:
Failed to reconnect to the server. [Retry?]
message:Expected behavior
A page should show up
Additional context
dotnet --info
:And here's what's relevant in the CSPROJ:
The text was updated successfully, but these errors were encountered: