Tagged with ASPNETCore
I've been using Azure App Services (e.g. WebApps) for a few years now. I've been mostly happy with the result. Though I've had some trouble with the way that the App Service environment works from time to time (mostly with the version of .NET Core that is running).
To try and eliminate that (and possibly save some cost), I decided to switch my apps to use Docker Containers. I thought I'd share how I did it in case you want to do this as well.
This will be a three part series:
I was reading my newest issue of MSDN Magazine and came across Julie Lerman's great article on how to configure Logging in Entity Framework Core. While this is great information, it only covered logging Entity Framework Core from a non-ASP.NET Core project so I figured I'd explain how to do it in ASP.NET Core.
The biggest thing that is different from the way that Julie shows this is that ASP.NET Core automatically wires up the ASP.NET Core logger to the context when it injects a context into your project. So to see Entity Framework Core logging, you need to enable it your ASP.NET Core logging, not in Entity Framework Core.
First let's talk about how Logging is handled in ASP.NET Core. In your
Program.cs file, the
WebHost.CreateDefaultBuilder() automatically sets up logging:
As ASP.NET Core 2.2 is now in preview, i've been looking at some of the early features for an update to one of my Pluralsight courses. ASP.NET Core 2.2 includes a number of new features, but this is a feature I really like.
If you haven't seen the whole list of new ASP.NET Core 2.2 features (in Preview 3 as of the updating of this post), take a look at the announcement here: blogs.msdn.microsoft.com.
UPDATE: 2.2 Preview 3 Changes this behavior