# Seamlessly debug Entity Framework Core SQL commands

Mar 6, 2018 3 minute read

Entity Framework Core (EF Core) is a lightweight ORM for .NET Core. It is a complete rewrite that maintains most of the functionality of Entity Framework. EF Core brings some exciting new features such as multi-platform support. And it also misses capabilities such as the ability to seamlessly debug the generated SQL. The EF Core team is tracking this issue. In the meantime, here’s my solution to the problem.

TL;DR: Use my DebugEFCore nuget package

Before: Entity Framework

Entity Framework provides a convenient way to debug the database commands being executed.

using (var context = new SampleContext()) 
{ 
    context.Database.Log = Console.Write;
}

After: EF Core

I created the DebugEFCore nuget package to achieve the same behavior.

using DebugEFCore;

public class SampleContext : DbContext
{
  protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
  {
    var debugLoggingEnabled = true;
    optionsBuilder.EnableLogging(debugLoggingEnabled);
  }
}

How does it work?

EF Core has some built-in capabilities around logging that potentially allow the debugging of the executed SQL commands. This debugging doesn’t come without a fair share of effort and knowledge. The DebugEFCore nuget abstracts away the complexities of dealing with the EF Core internals.

Existing EF Core infrastructure

The DbContext class provides a virtual OnConfiguring method that gets invoked for every context instance.
The OnConfiguring method receives a DbContextOptionsBuilder parameter.
The DbContextOptionsBuilder class has a UseLoggerFactory(ILoggerFactory) method to configure the DbContext logging.

`DebugEFCore` internals

Create an implementation of the ILoggerFactory interface. This implementation will proxy every log message it receives to a log4net logger. Detailed Source Code.
The nuget adds an extension method EnableLogging to the DbContextOptionsBuilder class. This method will call the DbContextOptionsBuilder.UseLoggerFactory only when logging is necessary.

FAQs

Why debug the SQL code an ORM produces?

ORMs abstract away many of the complexities of dealing with databases. They streamline the development process and help engineers focus on the task at hand.

Many software projects work for years without encountering performance problems. Others are not so lucky: processes start to take longer, applications crash randomly, the same code doesn’t work in different environments.

The database is usually a smoking gun during performance issues. The problem with ORMs is that they abstract away the database interactions. A minor change in the ORM usage could ripple into major database performance issues. In times like these is necessary to debug the generated SQL code in order to effectively tweak the ORM usage.

Are ORMs bad?

No. They are just tools. Martin Fowler’s views on the subject.

Should I write my own SQL commands?

No. Replicating an ORM feature set is a gargantuan task. Similar Stack Overflow question.

Tdd Apps