DiagnosticSource.BeforeView/AfterView not called in RenderPartial

[NickCraver]

I was trying to move from wrapped views to DiagnosticSource for MVC profiling in ASP.NET Core, but I've come across a major difference in behavior.

Currently, DiagnosticSource.BeforeView and .AfterView are called for regular views (here):

DiagnosticSource.BeforeView(view, viewContext);

await view.RenderAsync(viewContext);

DiagnosticSource.AfterView(view, viewContext);

Compared to the RenderPartial (and Async, etc.) pipeline (here):

await viewEngineResult.View.RenderAsync(viewContext);

...it's not wrapped in DiagnosticSource. The result is that instead of a rich profiling tree I can narrow issues down in like this:

The best I can get is:

Was this an intentional decision?

• If so: why?
• If not: can I submit a PR to add the .BeforeView and .AfterView calls?

[rynowak]

Was this an intentional decision?

We've only implemented DiagnosticSource eventing when/where someone has specifically asked for it 😆. I see no reason why we can't fix this.

What's your proposal for the details of the event?

@Eilon - opinion on a breaking change to

Mvc/src/Microsoft.AspNetCore.Mvc.ViewFeatures/ViewFeatures/HtmlHelper.cs

Line 42 in 8f8bf5a

public HtmlHelper(

to add the DiagnosticSouce as an additional constructor arg?

[NickCraver]

What's your proposal for the details of the event?

I'd expect it (naively) to call BeforeView with the same args as exist today - but if for some reason a BeforePartialView is desired...I don't suppose it matters much either way.

[Eilon]

@rynowak I'm ok with a breaking change to this, though we can also do it without a breaking change by adding a 2nd ctor that has the extra param, and have the current ctor chain to the new one. I'm fine either way.

[rynowak]

I feel like since this is 2.0.0 we might as well go ahead and add the extra arg and not deal with the perma-cruft of an obsolete constructor. This is the default implementation of the IHtmlHelper<> and it's almost always created by DI.

[rynowak]

@NickCraver - It looks like the existing code gives BeforeView/AfterView for both partials and views when they are returned from a controller - so yeah let's just keep using those.

Feel free to send a PR.