13

I'm trying to use the mvc-mini-profiler with EFCodeFirst I'm creating a DbProfiledConnection and passing it to the DbContext on construction as below. The application continues to work as expected by the sql is not exposed to the Profiler.

public class WebContext : DbContext
{
    static DbConnection _connection = new SqlConnection(ConfigurationManager.ConnectionStrings["WebContext"].ConnectionString);
    static DbConnection _profiledConnection = MvcMiniProfiler.Data.ProfiledDbConnection.Get(_connection);        

    public WebContext()
            : base(_profiledConnection, true)
    {   

    }

oops my bad.

I've modified it so that when my WebContext is constructed in my UnitOfWork i pass in a ProfiledDbConnection

public UnitOfWork()
{             
    var profiledConnection = MvcMiniProfiler.Data.ProfiledDbConnection.Get(connection);
    this.context = new MyContext(profiledConnection);
}

I've checked and MiniProfier Current has been set in Application_BeginRequest and it returns a ProfiledDbConnection when I then try and query the database an error is thrown in the ProfiledDbProviderServices class.

 protected override string GetDbProviderManifestToken(DbConnection connection)
 {
     return tail.GetProviderManifestToken(connection);
 }

this method returns a "The provider did not return a ProviderManifestToken string." error

Sam Saffron
  • 128,308
  • 78
  • 326
  • 506
Richard Forrest
  • 3,567
  • 2
  • 23
  • 32
  • 6
    btw, a static connection is dangerous - it should be request-specific. – Marc Gravell Jun 09 '11 at 11:08
  • Why is a static connection dangerous? Also, am I actually using a static context if I initiate a new context only at the top of my controller and not in each request? – sirtimbly Jun 27 '11 at 19:56

1 Answers1

7

I suspect this relates to the static field initializer. Connections on web apps should never be static anyway (but request-specific at most).

The key is: what does ProfiledDbConnection actually come out as? The Get method returns a ProfiledDbConnection only if you are currently profiling (on the current request), and the connection is profiled against the MiniProfiler instance on that request.

If you use a static field, then there are two scenarios:

  • the static field is initialized without a request context (or a non-developer request context): no profiling will occur as MiniProfiler.Current is null
  • the static field is initialized, but everything is logged against the very first request, which is quickly dead
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • A big +1. There's little point in profiling a app with a static context reference. You can tell just by looking that it will have problems! – Craig Stuntz Jun 09 '11 at 12:28
  • oops my bad. I've changed my code but am now getting a token exception in ProfiledDbProviderServices – Richard Forrest Jun 09 '11 at 16:07
  • 1
    @feanz ah right; ok, EF codefirst isn't a tool I use, so I haven't validated that scenario. However, we've had (today) a user volunteer a patch for EF code first. Give me a few hours to merge etc – Marc Gravell Jun 09 '11 at 16:25
  • Let me know when you have applied the patch as I could pull the code and help test it. – runxc1 Bret Ferrier Jun 09 '11 at 20:09
  • i m having strange problem when using mini profiler with linq to sql please have a look at http://stackoverflow.com/questions/6410756/using-different-overload-of-datacontext-in-linq-to-sql – Muhammad Adeel Zahid Jun 21 '11 at 06:07