Watching the SQL queries Entity Framework executes is quite useful when a slow query needs optimization. If you’re already using ASP.NET Core, you might have already noticed that the debugging stream already outputs these SQL queries for you. But, if you’re working with ASP.NET MVC or ASP.NET Web API projects, by default you won’t see the SQL queries executed by EF.
Entity Framework is an amazing ORM. It has differences with other ORMs like Hibernate or Doctrine, but at the same time feels more comfortable. Two key differences with other ORMs are LINQ as its query language (LINQ it’s a compiled language, if you like to rename stuff you know how many errors this feature can prevent) and being able to use foreign key values without having to join with the related entity.
ASP.NET MVC provides several ways to serve files from controllers, but all of them require to serve the entire file content through the network, something that will make our website slow and more expensive while it’s ridiculous to transfer the same content over the network every time the resource is requested. Client-side HTTP caching can easily prevent downloading all those extra bytes. In this post we offer a solution to it without doing any complicated stuff, using the ActionResult abstract class to integrate a solution based on ETags in ASP.NET MVC to implement the client-side caching.
I’ve made my mind to do this post just because I saw there wasn’t a solution to what happened to me with this problem, even though the solution to it was pretty naive to me. The thing is, in an ASP.NET project, I have a publish profile with precompilation enabled and with the advanced precompile option “Merge all outputs to a single assembly” enabled too. I decided to set to this output assembly my project name, something that seemed to me the right thing to do. But then, suddenly a misterious error showed up.