Catalog differences between runtime and designtime content from compiler

[phil-allen-msft]

The goal here is to, across the suite of features, understand what additional content the compiler would need to emit in order to have the runtime content power the existing IDE/tooling/designtime features.

[ryanbrandenburg]

IIRC the plan here was to clone @chsienki's branch with the DesignTime stuff removed/disabled and exercise things, see where they break, by how much and we can plan further from there. @chsienki would this be that branch and is it ready for me to investigate on?

[phil-allen-msft]

https://github.com/dotnet/razor/tree/features/disable-design-time is the right branch (you have it)

[davidwengier]

• Source mappings are missing for most things
  • Added the "easy" ones here: 43702f0 (#8455)
• Worth noting that tooling features are highly sensitive to exact positioning of source mappings.
  • If it turns out the whitespace differences are deliberate perf/output optimizations done by the compiler then this could be an issue. For example: On the left, with source mapping from the above commit, various tests fail because having the caret at the < of the <br /> tag is classified as markup, not code.
• Source mappings for attributes and attribute contents are slightly harder to add in, due to differences in code architecture, so I didn't add them.
  • For example, currenty a component like <Goo Prop="Val" /> has no generated reference to the actual property on the component that is represented by the Prop attribute. Fixing this requires generating code at runtime just to support the IDE, so we should work out a strategy for how do that in the best way.
• It occurs to me that the number, original location, and content of source mappings should be identical between design and runtime. The order and the generated location don't need to be. Maybe its worth crafting a test that validates that specifically?
• Various formatting behaviours depend on knowing exactly what the C# formatter does to the generated code, so will need to be adjusted.
  • This is probably a good thing, as if runtime code uses less lambdas, it should make for a better formatting experience for users
• Some tooling tests will need to be updated because the runtime generation references more of the ASP.NET Framework, and .NET Framework, than design time. Should be irrelevant in practice in VS though.

[davidwengier]

No idea if it's useful, but I'm creating https://github.com/davidwengier/AllRazorAndBlazor to try to get something that has every single Razor feature in use

[ryzngard]

Current Status

Failed tests in CI on https://github.com/dotnet/razor/pull/9825

Integration tests run (still running) https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=8935944&view=results

Manual Testing

Small Blazor App (Release Build)

Feature	Status	Notes
Completion of Attribute	✅
Completion of HTML	✅
Completion of TagHelper	✅
Diagnostics	❌	See (1), (2) below
FAR from .cs	✅
FAR from .razor	✅
GoToDef From .razor	✅
Hover C#	✅
Hover HTML	✅
Hover Tag	✅
Hover Attribute	✅
NavBar	✅
Rename from .cs	✅
Rename from .razor	❌	See (3) below
Spelling	⚠️	Squiggle seems off. (4) Below

1

The #line directive end position must be greater than or equal to the start position BlazorApp1 (net6.0) C:\Users\ryzng\source\repos\BlazorApp1\BlazorApp1\Pages\FetchData.razor 30

#line (31,26)-(31,1) 25 "C:\Users\ryzng\source\repos\BlazorApp1\BlazorApp1\Pages\FetchData.razor"
__builder.AddContent(13, forecast.Date.ToShortDateString());

#line default

Steps to reproduce:

1. Create new blazor server app
2. Find All References onWeatherForecast from WeatherForecast.cs
3. Open a reference in FetchData.razor

2

Missing error for missing callback. OnCopy does not exist

<button class="btn btn-primary" @onclick="IncrementCount" @oncontextmenu="OnCopy">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

3

Razor file renaming Forecast -> WeatherForecast results in

4

[phil-allen-msft]

Status = Done