Can't redirect Trace.WriteLine to Serilog using SerilogTraceListener - trace

In one of my project (.net core 3.1), I need a way to redirect System.Diagnostics.Trace.WriteLine to Serilog file. I found the SerilogTraceListener package which seems to be the right candidate.
Unfortunately until now, I haven't been able to find a way to make it works.
To reproduce it,
1) Create a .net core console project
2) Add the following nuget package : Serilog, SerilogTraceListener, Serilog.Sink.Console, Serilog.Sink.File
3) Overwrite the Program class code by the following
class Program
{
static void Main(string[] args)
{
// Works fine
Log.Logger = new LoggerConfiguration()
.WriteTo.Console()
.WriteTo.File("log.txt")
.CreateLogger();
Log.Logger.Information("A string written using Logger.Information");
// Trace is written in the console but not in the file
Trace.Listeners.Add(new ConsoleTraceListener());
Trace.Listeners.Add(new global::SerilogTraceListener.SerilogTraceListener());
System.Diagnostics.Trace.WriteLine("A string written using Trace.WriteLine");
}
}
What am I doing wrong?

TL;DR; You need to set the MinimumLevel to Debug or Verbose in order to see the Trace.WriteLine messages.
SerilogTraceListener maps System.Diagnostic.TraceEventType to Serilog.LogEventLevel, and when you call Trace.WriteLine, it maps these events to the Debug log event level.
That means Serilog's logger is receiving a message of type LogEventLevel.Debug.
The minimum level configured in Serilog by default is Information, which means Debug messages are being suppressed.
You have to configure the MinimumEventLevel to Debug (or Verbose) in order to see the Trace.WriteLine messages:
Log.Logger = new LoggerConfiguration()
.MinimumLevel.Debug() // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
.WriteTo.Console()
.WriteTo.File("log.txt")
.CreateLogger();

Related

Log aspect in PostSharp 5.0.23 not applied at assembly level

I am following the steps mentioned in http://doc.postsharp.net/add-logging . The Visual studio version is 2017 and PostSharp 5.0.28 extension is installed. When the log aspect for console backend is added to the whole project, the GlobalAspect.cs file is added but the output shows no log trace. But when I apply the [Log] attribute to the method the log trace is seen. Why is the definition in GlobalAspect not applied?
using PostSharp.Patterns.Diagnostics;
namespace ConsoleApp1
{
[Log(AttributeExclude = true)]
public class Program
{
static void Main(string[] args)
{
LoggingServices.DefaultBackend = new PostSharp.Patterns.Diagnostics.Backends.Console.ConsoleLoggingBackend();
}
public static void f()
{
}
}
}
I have the following entry in GlobalAspects.cs file of console and dll. While in dll it works, the console it doesn't.
[assembly: Log(AttributeTargetTypeAttributes=MulticastAttributes.Public‌​, AttributeTargetMemberAttributes=MulticastAttributes.Public)]
Unfortunately, GlobalAspect seems to have no impact on Console application. On a class library, it does work neat.
When you apply the [Log] aspect on the assembly level, it is propagated to the methods in the assembly according to the specified rules.
You can set properties such AttributeTargetTypeAttributes, AttributeTargetMemberAttributes to specify whether you want to target public,private, instance, static methods etc. You can also specify the namespace, type and member names.
The defaults for these properties may not correspond with what you want. You need to make sure that the specified properties match the characteristics of the desired target methods.
[Log(AttributeTargetTypeAttributes = MulticastAttributes.Public, AttributeTargetMemberAttributes = MulticastAttributes.AnyVisibility)]
You can find more details on this documentation page: http://doc.postsharp.net/attribute-multicasting

Create Framework and Ambiguous reference to member 'log'

I'm having quite the time trying to turn my code into a Cocoapod / Framework.
So I have some code that I'd like to package into a framework (F) and then use that in App (A). It is almost working, however, when I try to build A (who links F), where source in A references the log from F, I get an error
Ambiguous reference to member 'log'
This is because log is defined in my sources for F in a file named Logging.swift, and looks like this:
import Foundation
import XCGLogger
// MARK: - Logging
let log: XCGLogger = {
let log = XCGLogger(identifier: "mainLogger", includeDefaultDestinations: false)
// Create a destination for the system console log (via NSLog)
let systemDestination = ConsoleDestination(identifier: log.identifier+".console")
// configure it here, omitted for brevity
// Add the destination to the logger
log.add(destination: systemDestination)
// Add basic app info, version info etc, to the start of the logs
log.logAppDetails()
return log
}()
My questions are:
i) How do I get rid of this error? I'm guessing it has something to do with specifying which module is logging this, because there are other modules that also have a log. (Darwin, CoreGraphics, etc.)
ii) How do I set up my logging so that anything that would be logged in framework F code could also be included in the same logger for App A ? Is that even possible or necessary?
I believe I can now answer my own question:
I changed the Framework's Logging.swift file to:
public struct Log {
public static var main: XCGLogger = {
let log = XCGLogger(identifier: "mainLogger", includeDefaultDestinations: false)
// Create a destination for the system console log (via NSLog)
let systemDestination = ConsoleDestination(identifier: log.identifier+".console")
// Optionally set some configuration options (omitted for brevity)
// Add the destination to the logger
log.add(destination: systemDestination)
// Add basic app info, version info etc, to the start of the logs
log.logAppDetails()
return log
}()
}
Then it has a default logger. I reference calls to the log with Log.main
In my Application A, I can define my own logger, and just assign it:
Log.main = myOtherLog

How to make EF log sql queries globally?

How do I "tell" EF to log queries globally? I was reading this blog post: EF logging which tells in general how to log sql queries. But I still have a few questions regarding this logger.
Where would I need to place this line context.Database.Log = s =>
logger.Log("EFApp", s);?
Can it be globally set? Or do I have to place it everywhere I do DB
operations?
In the "Failed execution" section, the blogger wrote that, and I
quote:
For commands that fail by throwing an exception, the output contains the message from the exception.
Will this be logged too if I don't use the context.Database.Log?
Whenever you want the context to start logging.
It appears to be done on the context object so it should be done every time you create a new context. You could add this line of code in your constructor though to ensure that it is always enabled.
It will not log if you do not enable the logging.
I don't recommend to use that's functionality, because, it hasn't reason to exists in the real case.
Thats it use a lot of to debug code only. But, wether you wanna know more than details ... access link... https://cmatskas.com/logging-and-tracing-with-entity-framework-6/
In this case you can put code like this
public void Mylog()
{
//Thats a delegate where you can set this property to log using
//delegate type Action, see the code below
context.Database.Log = k=>Console.Write("Any query SQL")
//Or
context.Database.Log = k=>Test("Any query SQL")
}
public void Test(string x){
Console.Write(x)
}
I hope thats useufull

Debug code-first Entity Framework migration codes

I'm using Entity Framework code first in my website and I'm just wondering if there is any way to debug the migration codes. You know, like setting breakpoints and stuff like this.
I'm using Package Manager Console to update the database using Update-Database.
Thanks
I know that EF Code First Migrations is relatively new tool but don't forget about you are still in .NET.
So you can use:
if (System.Diagnostics.Debugger.IsAttached == false)
{
System.Diagnostics.Debugger.Launch();
}
After that you can see your InnerException.
Or you can use try...catch statement like this:
Exception handling Entity Framework
To hit a break point in a db migration set the context to MigrateDatabaseToLatestVersion on initialise.
Database.SetInitializer(new MigrateDatabaseToLatestVersion<EnterContextHere, Configuration>());
Then you just debug as normal (run using f5) and the breakpoint will hit the first time you run the project.
The problem now is that if you debug a second time the migration will not run. This is because the __MigrationHistory table has been updated to say you have migrated to the latest version. To re-test the migration open the package manager console and downgrade to the previous migration:
Update-Database –TargetMigration: ThePreviousMigrationName
My answer might be a bit silly but anyway here it goes.
If you, like me, some times have problems in the Seed() method what I usually do is simply create a public method that calls the Protect Seed().
public void SeedDebug(AppDbContext context)
{
Seed(context);
}
then in my HomeController I call this method in Debug mode.
public class HomeController : Controller
{
var appDb = new AppDbContext();
public ActionResult Index()
{
var config = new Configuration();
config.SeedDebug(appDb);
return View();
}
}
I know it's a bit lame solution, but it's simple and quick.
Of course this has to be done after the model been created.
So step by step:
comment the seed method and execute the update-database to create the model
uncomment the method Seed() and plugin the "hack" I mentioned above.
in the configuration disable Auto migrations
AutomaticMigrationsEnabled = false;//if you have this disabled already skip this step
Debug your application, fix the error and remove the "hack"
Here's a more fail-proof method which will do the trick without much fuss:
Step#1: Place this piece of code right above the migration you want to debug:
public partial class ORACLE_Test : DbMigration
{
public override void Up()
{
if (!System.Diagnostics.Debugger.IsAttached)
System.Diagnostics.Debugger.Launch();
AddColumn("TEST", "UR_USER_ID", x => x.Decimal(nullable: false, precision: 11, scale: 0, storeType: "number"));
AddColumn("TEST", "UR_CLIENT_ID", x => x.Decimal(nullable: false, precision: 11, scale: 0, storeType: "number"));
[...]
}
public override void Down()
{
}
}
Step#2: Compile the project containing your migrations
Step#3: Open a console inside the output directory (/bin/Debug, /bin/Release etc) containing the dll of your migrations
Step#4: Invoke migrate.exe with the /scriptFile parameter to launch the debugger and actually debug the desired db-migration
migrate.exe "Your.Migrations.Assembly.dll" /scriptFile="foo.sql" /verbose /startupConfigurationFile="Your.Migrations.Assembly.config"
Once the debugger-selector dialog pops up pick the visual studio instance that you have already opened.
You could add Console.WriteLine statements to the migration code (not a great solution)
Note, the messages are only shown if you run the migration code using the migrate.exe utility (in pacakges\EntityFramework.x.y.z\tools). They will not display if you run the migration through the Package Manager console.
I've had lots of luck using "Debugger.Launch()" (like in m_david's answer above) elsewhere, but inside of CreateDbContext it seems to somehow both attach, and not attach. What I mean is, it attaches and starts trying to step into .asm files and .cpp files (internal code). If I try to set a breakpoint on a Console.Writeline that I KNOW gets executed afterwards (I can see the output from ANY "dotnet ef migrations COMMAND") it both executes it and never hits the breakpoint.
This is what worked for me instead:
while (!System.Diagnostics.Debugger.IsAttached)
System.Threading.Thread.Sleep(10);
// Breakpoint after this...
You can execute the migration and manually attach using Visual Studio and it will actually let you step through the code like you expect, it's just more of a pain. What I should really try is the combination of both methods...
I also found a neat trick here to get the error details...
Basically, the trick is to grab all the information from an exception, put it in a string and throw a new DbEntityValidationException with the generated string and the original exception.

EventLogInstaller Full Setup with Categories?

It appears the MSDN docs are broken concerning creating an Event Log completely along with a definitions file for messages. I am also lost on how to setup Categories (I have custom numbers in the 3000's for messages).
Can anyone point me to a link or show sample code on how to make this right?
You should start (if you haven't done so already) here:
EventLogInstaller Class (System.Diagnostics)
The sample provided there is the foundation for what you want to do. To sum it up, build a public class inheriting from System.Configuration.Install.Installer in an assembly (could be the same DLL where you have the rest of your application, a separate DLL, or an EXE file), decorate it with the RunInstaller attribute, and add your setup code in the constructor:
using System;
using System.Configuration.Install;
using System.Diagnostics;
using System.ComponentModel;
[RunInstaller(true)]
public class MyEventLogInstaller: Installer
{
private EventLogInstaller myEventLogInstaller;
public MyEventLogInstaller()
{
// Create an instance of an EventLogInstaller.
myEventLogInstaller = new EventLogInstaller();
// Set the source name of the event log.
myEventLogInstaller.Source = "NewLogSource";
// Set the event log that the source writes entries to.
myEventLogInstaller.Log = "MyNewLog";
// Add myEventLogInstaller to the Installer collection.
Installers.Add(myEventLogInstaller);
}
}
When you have your assembly compiled, you may use the InstallUtil tool available through the Visual Studio Command Prompt to run the installer code.
Regarding the message definition file (which includes category definitions), the MSDN documentation for EventLogInstaller.MessageResourceFile mentions that you should create an .mc file, compile it, and add it as a resource to your assembly. Digging around, I found an excellent post which should guide you to the end, here:
C# with .NET - Event Logging (Wayback Machine)