In this video tutorial, we'll look at the basics of getting Serilog configured in your ASP NET Core application and how you can wire it all up with appsettings.json!
View Transcript
In this video, we're going to look at setting up Sarah log in an ASP.NET Core web app using app settings configuration. With Sarah log, we can set all of our configuration up in code if we want to. But if you're interested in using it from app settings, and this is going to show you quite easily how you can do that with really not many lines of code to actually enable it. We'll go through a couple of gotchas in terms of where you can use the logger. But otherwise, if you stick right to the end of this video, we'll look at how you can navigate some of these things with either ChatGpt or Copilot and some of the differences in the answers that you might get. So, let's jump over to Visual Studio and check it out. What I have done on my screen right now
is I've just set up a new project in my solution. It has a really lengthy name, ASP.NET Core Sarah Logg from app settings example. So, this is going to be in my repository that I will have up on GitHub. So, if you're interested, I do have my dev leader examples. Not all of them, but a lot of them go up to GitHub from all my video tutorials. But I would honestly say that the code that I'm going to be adding here, it's not really going to be groundbreaking in terms of you, you know, needing to pull this code down and use what I'm writing. If you follow along, it should be hopefully pretty straightforward. And then you don't have to take any code that I'm using. The first thing that I want to show you is that we're going to be able to add logging
like this. So, we take an I logger. We can say logger like this. And then we could do something like thanks co-pilot so much. And we'll do another logger. Cool. So we can do log lines like this inside of our minimal API. And we'll talk about a couple of other spots for logging like what happens if we want to log in startup and what that means. First thing that we need to be able to do is get the required Nougat packages. So I've cheated a little bit. I apologize, but I've already added a couple into here. I have to look over at my other screen because my camera is blocking exactly where the code is. I do have these three packages. I have Serilog ASP.NET Core. This is going to be the important one for us because we're working ASP.NET Core. But really the magic
is happening from this package here. And if you actually read a little bit of the documentation on the Nougat package, like when you go to search for this one and you see it listed in Visual Studio, it actually shows you in the app settings or sorry, it shows you an example of app settings where you can have all this stuff configured. So this is the one that's going to let us sort of link up app settings and Sarah log together. And then finally, I'm just going to be using this one down here as a sync. We're going to use the console. If you're not familiar with the concept of syncs, it's just where are we logging to. So this is sort of a you know generic term that we use in logging. This is what Sarah log sticks to and it's not just console. You
can get you know a file sync, you can get a rolling file sync. You could have a sync that is a cloud service. So there's all sorts of places that you can log to. We're just going to use the console for this example. If you're looking at the versions here and you're worried because you're following along and you're going, I got different versions. Probably totally okay. No promises, but it should be fine. They could have breaking changes, but uh Sarah log has been quite stable for quite some time. So, I highly doubt for the stuff we're looking at, you'll have any issues, so don't panic. Now that we have that in place, if we go over to program.cs, CS. We're going to look at the couple of lines of code we need to actually get Sarah log wired up as the logging framework for our
web app and having it read from configuration. So, first thing we're going to do is at the top using Sarah log. Okay, I'm going to add this. You'll notice if you're paying attention, I get a red squiggly under logger right away. And that's because this is a type that is used in both Sarah log and the Microsoft extensions namespace. Just to make this a little bit easier as we go through this, I'm just going to alias I logger to be the Microsoft extensions. Come on, co-pilot logging. Again, this is right behind my camera, so it's making my life really interesting. So, now that we have this logger in place down here, and we have this alias, we can just use i logger wherever we would like and not have to worry about Sarah log conflicting with us. But the next step is that we actually
have to hook this thing up, right? So, we're going to go here right under creating a builder. Again, this is a pretty uh basic or introductory ASP.NET Core concept, but we're dealing with a web application, of course, and we have a web application builder. So, as we're building this thing up, this is where we configure all of our services and stuff like that that we do all this before we go run the application. So, we're going to say builder host and then we are going to say set up or use serial log. There it is. And very fortunately for us, Copilot is doing a bunch of this. We don't need all of it. So, I'm going to get rid of a little bit just to make it slightly more straightforward for us to talk through. Copilot, you're doing too much. Okay. So, what we have
in here, and I keep glancing over because again, my camera is blocking over uh this code right here. I wanted to show you with the tool tips. So this is the host builder context. This is the service provider. So this might be a little bit more clear if you're playing with dependency injection stuff. There's a service collection and a service provider. The collection is what you use as you're building things up. And the provider is what you're using to resolve the services that you have registered. And then this configuration at the end. And this configuration is the logger configuration. So now that we have that, I took it off my clipboard, but you can see we need to do just this top line. This here is going to allow us to get the configuration for Sarah log read from the actual config that we have
in app settings JSON. This basically lines 6 to9 is all we need to get things read in. It's truly that simple. We're going to get app settings. Well, I think I already copied it over. Yes, I have an example app settings just so you can see. We will walk through this super quick, but we have log levels, right? So, if you're not familiar with some of these concepts, just to briefly mention, if we have app settings development JSON, it means that if we want, we can have different logging levels by default for development. So, maybe in development, you want to set your log level to debug. And that way, when you're running stuff in your local environment, you can see all the log information, all your debug log statements. But in production, you're using not app settings development. It might just be app settings.j JSON
or app settings.production.json and you can have different log levels just in the config. The other thing that you can do is you can change your template. Right? So this is the console one that we're going to be using. There's a enrichment here. I'm not going to go into details for this video, but we have this here. And what we're able to do if you look at this line on 16 is set up the format for the logging messages that we're going to be playing with. Okay. So there's an app settings. By the way, if you don't have one of these, you're not sure how to set it up. If you go to the Serilog documentation on GitHub, it will absolutely walk you through how you can do this, and like I said, if you say to the end of this, we'll talk about using C-Pilot
and uh and chat GPT to be able to help us navigate setting up one of these. So, lots of options. Don't panic. You don't need this exact configuration to make this work. Okay, so this code will now load up our app settings for Sarah log. And really at this point, we could go run this and we're going to get logging when we hit our minimal API. But I wanted to touch on one more thing that's a little bit of a bonus for this video. And that's like, well, okay, we can log in the minimal API. That's lovely if you trust me that it's going to work. But what about if we wanted to log elsewhere? Okay, like what if I wanted to log right up here? Well, the tricky part with hooking up Sarah log and this is going to be similar for other logging
infrastructure. The challenge with hooking it up when you're building all these things is that we don't have it configured at the time we want to go use it. So line five where I have my cursor. If I want to try to resolve a logger from the dependency container, we haven't we haven't done anything. We don't have a logger yet. And in fact the default Sarah log logger if we wanted to use log like this and then say debug for example the default logger that comes from Sarah log doesn't log anything. So this line sort of works but it doesn't actually do anything. You could have some logging statements like this. You could say starting up the application. I might say building the application. Application built successfully, right? Like we could go do that. But the challenge is that like I said this won't actually log
anything. So let's prove it right before we go fix this. So we're going to go run this. So here's the console running. You can see there's literally nothing in the console. If we didn't touch any of the logging, you'd actually see more logging from ASP.NET Core manually writing stuff out to the console, but we've sort of taken that over. We've hijacked all of the logging. So truly, it's not doing anything. But what I want to do is get a browser open up here. We're going to hit the weather forecast endpoint, and we'll see some logs. Okay. So, what I'm going to do is press enter when we go to this weather forecast route. But we have a problem. And this is something that I made a little mistake at the beginning of this video and I should have caught it. But generally we don't use
eye loggers directly like this. And there's a reason for that. Especially with structured logging, it's better for us to have a type on the logger. So we're in the program class, if you will. If you were doing this in other classes, generally you would have a typed logger like this because it takes a type parameter in. This will add more context into the logging. So, we actually don't need this line up at the top. You can see that. Might be kind of hard to see, but Visual Studio is saying, "Hey, you're not really using this alias anymore." That's right. This problem here or this problem you're seeing will be fixed by this because we will be able to resolve this. If you truly want to be able to resolve just an eyeloger interface, we have to do a little bit more setup in terms of
the dependency injection. in my opinion, not really worth it because you should basically always be trying to use uh a typed logger like this. If we go ahead and run this again, we'll pull this up again. No logging yet at the startup. We're going to come back to this in just a moment. Now, if we go run this again, we should get logging, right? So, we can see that we have our structured logs from Sarah log coming in. So, we have the one at the beginning and the one at the end. So, these two log lines, what is going on with Visual Studio? Uh, we have these two log lines. This one here on 36 and this one here on 26, but we're still not getting these ones. So, before I demonstrate that, just a super quick recap. In order to get things loading up,
we have our three Nougat packages. We have this chunk of code right here that basically tells the web application builder, let's get Sarah log hooked up as our logger, and you need to load from configuration. So, the app settings. Okay. And then down here, we're able to resolve a logger to use it, but we're going to use a typed logger because the eyeloger interface is a generic. If you're not sure what class we're in right now, by default at the top level, we're in program. This is something that's a little bit less obvious when you move away from program. Well, we're in program.cs, CS, but when you don't have a program class with a main method, this is maybe a bit of history for some people at this point. But if you're in a different class, you would use that class name here as the
type parameter for your logger. So, in order to get these logging statements to work, like on line 3, 11, and 13, like I said at the beginning of this video, Sarah log when you go to use the logger here, like this logger off of the log static class is not configured to log anywhere yet. So, copilot was kind of cheating and showing us what we need to do almost. It's not exactly this. If you run this, it will sort of kind of work, but it's still not exactly what we need. So let's walk through what this does and then I'll explain the extra line we have to go configure here. But this is going to tell us or tell Sarah log make a new logger. This is where it's going to write to. So we're saying use a console sync and it's a bootstrap logger.
So what I want you to think about is that if you're not familiar with like what bootstrap means this is just meant to suggest like when we're starting something off. So before the application's running. But what's not included here and it's not super obvious is we're not telling Sarah log what log levels to use. So we actually need to say something like this or you can say like maybe you only want information log levels. We have debug logs right like here and here. So we want debug as the minimum level. Okay. So what I'm going to do is run this. We're going to see where we log and we're going to talk about that. Okay. So you might notice something interesting. We're getting log lines. That's great. I have three log.debug lines and we can see only two. So we can see starting up the
application and building the application. But what's interesting is after this line here app equals builder.build all of our dependencies are wired up. Okay. So technically we've now said go use the Serog logger. But what's really interesting, at least in my opinion, is that at this point once we build, we're using the Serog logging from configuration, but we haven't actually started the application. So, we can't use the logger yet. There are some ways around this like you could basically do another bootstrap in between. Depends how much logging you want, where you want to log. You could store a reference to this logger, right? You can see with the tool tip, this is Sarah log eyeloger. So instead of using the static one like this, you could assign it to a Sarah log eyeloger, pass that through. You have lots of options, but the point is that
this is bootstrap logging and it's going to be different from the one that you actually set up in this configuration. So if all you care about is configuring logging to use uh downstream after your application is already up and running like on your API endpoints and things like that, this is sufficient to get it configured and to have it all pulled in from app settings so you can change the settings there and have those take effect in your application. So hopefully you found that helpful. And like I said, if you stayed to the end of this one, we're now going to talk about how you might navigate this with either chat GPT co-pilot, your favorite AI tool, and how you get slightly different answers. So if you're interested in that, you can check it out right here. Thanks, and I'll see you in the next
one.