MiniProfilerWebFormsEnabler

The StackExchange Mini Profiler is a nice tool to help you see where your pages and queries are spending most of their time. 

It gives you a little jewel in your page that you can click on to see info like:

demo

N+1

While setup is easy, I was going to build a way for it to be enabled/disabled on a per-session basis so that developers could tur n it off and on as needed.  So I decided to make it into a nuget package.

The nuget package is here:

https://nuget.org/packages/MiniProfilerWebformsEnabler

and the source is hosted here:

https://miniprofilerwebforms.codeplex.com/documentation

Adding a reference to this from your web project will cause the StackExchange MiniProfiler to profile for all requests (by default), but only show them to you if you choose to enable it for your session.  To enable display of the values, you simply browse to ~/MiniProfiler/true (or false to turn it back off).

Because the MiniProfiler will cache up to 15 request profiling sessions, this means a developer can notice a page took a long time to load, and after it completes, browse to ~/MiniProfiler/true to see the profile session that contains the info for what caused the slow page processing on the earlier request.

If you don’t want the profiler to always be monitoring, you can disable it with

MiniProfilerHttpModule.AlwaysProfile = false;

in your application startup code.

By default, the application will also always profile local requests.  This can be disabled with:

MiniProfilerHttpModule.AlwaysProfileLocalRequests= false;

Advertisements

7 thoughts on “MiniProfilerWebFormsEnabler

  1. Hello Chris,
    Your FormsEnabler works fine, standalone. I like the way we can turn Miniprofiler on and off.
    But it frustrates the ‘Elmah.axd’ we use for logging errors. It gets the following error:

    Session state is not available in this context.
    Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
    Exception Details: System.Web.HttpException: Session state is not available in this context.
    Source Error:
    An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
    Stack Trace:
    [HttpException (0x80004005): Session state is not available in this context.]
    System.Web.HttpApplication.get_Session() +3257280
    MiniProfilerWebFormsEnabler.MiniProfilerHttpModule.OnPreRequestHandlerExecute(Object sender, EventArgs e) +71
    System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +136
    System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +69
    Can you make the FormsEnabler coexist with Elmah?

  2. The package is 1.0.4. Miniprofiler itself was added by your package (is actually 2.0.2). Elmah is 1.2.2.
    When I uninstall just the webformsenabler everything works ok.

    • How are you producing the exception? Just by browsing to elmah.axd?

      I couldn’t reproduce this, but I did find an inconsistency with how I was handling session. I’ve updated the package to 1.0.5, can you test that version and see if you still have the issue?

  3. I tried 1.0.5 and it has the same (error) result. After uninstalling the package Elmah shows it page normally.
    What I do is simple: Start the website and sooner or later browse to elmah.axd (with or without errors). Environment is my development workstation (Win7 Enterprise on windows update). Changing between IisExpress and Cassini makes no difference.
    Web.config contains some WCF client configuration (and MVC routing for lightweight async calls) and a module/handler for DevExpress gridview. Does this help? (It is the end of my day, next comment tomorrow)

      • Used the source to compile a local version. No problems, everything worked (with or without DEBUG). Then I reinstalled the NuGet package (1.0.5) again and the problem was back. Looking for differences I found that the NuGet dll is version 1.0.0.0 and the dll that I created from the source is version 1.0.0.5. Could it be that the NuGet package does not have the latest version?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s