Skip to content
This repository was archived by the owner on Dec 14, 2018. It is now read-only.

DiagnosticSource.BeforeView/AfterView not called in RenderPartial #6222

Closed
NickCraver opened this issue May 2, 2017 · 6 comments
Closed
Assignees
Labels
3 - Done bug up-for-grabs Members of our awesome commnity can handle this issue
Milestone

Comments

@NickCraver
Copy link

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:
screen shot 2017-05-01 at 19 58 33

The best I can get is:
screen shot 2017-05-01 at 19 54 36

Was this an intentional decision?

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

rynowak commented May 2, 2017

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

to add the DiagnosticSouce as an additional constructor arg?

NickCraver added a commit to MiniProfiler/dotnet that referenced this issue May 2, 2017
Unfortuantely, this is blocked by
aspnet/Mvc#6222 which greatly diminishes view
insight. Rather than breaking down timings into any particular view,
they're all aggregated at the top view which is a major step backwards.
@NickCraver
Copy link
Author

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
Copy link
Member

Eilon commented May 2, 2017

@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.

@Eilon Eilon added 1 - Ready bug up-for-grabs Members of our awesome commnity can handle this issue labels May 2, 2017
@Eilon Eilon added this to the 2.0.0-preview2 milestone May 2, 2017
@rynowak
Copy link
Member

rynowak commented May 3, 2017

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
Copy link
Member

rynowak commented May 3, 2017

@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.

@rynowak rynowak modified the milestones: 2.0.0-preview2, 2.0.0-preview3 May 30, 2017
jbagga added a commit that referenced this issue Jun 26, 2017
@NickCraver
Copy link
Author

Implemented in #6386, closing out to cleanup.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
3 - Done bug up-for-grabs Members of our awesome commnity can handle this issue
Projects
None yet
Development

No branches or pull requests

4 participants