Find All References doesn't work on [Parameter] Setters anymore

[AdmiralSnyder]

I used to be able to find the places where the parameters of a razor component were used by clicking into the {get; set;} and hitting Shift-F12 - this apparently broke in VS 17.13 (nor does it work in VS 17.14 preview)

clicking into the get and hitting Shift-F12 still lists the places where the parameter is used, apparently.

[davidwengier]

This will be because of FUSE.

If we have a component <Foo Bar="Baz" />:

• Pre-FUSE we would have generated TypeInferenceMethod<Foo>().Goo = null;, so Roslyn would have seen it as a property set
• Post-FUSE we generate nameof(Foo.Goo) which I guess Roslyn sees as a property get. Or at least, certainly not a set.

I'm guessing FUSE doesn't have the type inference helpers any more.

[davidwengier]

Some more context: @AdmiralSnyder was using this to distinguish between when the property is specified as an attribute, versus referenced in code like @Bar. FAR on the property name shows both for me, but not for him, but also he said its very noisy, so its a bit of a regression.

[davidwengier]

Maybe this is a test case for "How do we deal with code-gen that makes the IDE better in a post-FUSE world?"

[jjonescz]

Technically, the setter is not referenced, it's only called by the aspnetcore runtime via reflection (I think). I guess it would be nice (and more performant although I'm not sure about that) if the compiler emitted something like

builder.AddComponentParameter(static (c, v) => c.Param = v, value);

instead of

builder.AddComponentParameter(nameof(Component.Param), value);

Otherwise, couldn't we introduce some API where we would tell Roslyn arbitrary mappings from Razor without the need for backing C# code? The source generator could emit these mappings. Like <Component |Param|="value" /> maps to Param.get/set symbol. And "the character 0 in file Component.razor" maps to class Component symbol (which would make #7213 work). Etc.

[davidwengier]

I guess it would be nice (and more performant although I'm not sure about that) if the compiler emitted something like

We talked about this issue in the working group meeting today and Dan brought up that there is actually an issue for something like that: dotnet/aspnetcore#29550

Otherwise, couldn't we introduce some API

I think there is definitely room for more interesting hooks into Roslyn once cohosting is a real thing.