Here's the situation: I'm working on a MFC application and want to integrate some logging capabilities into it. I did some research and settled on Pantheios since it seems to be regarded as the best logging API out there. I had no problems getting simple logging up and running - I even threw in some callback stuff to change the formatting of the output.
My application will be making use of several DLLs. These are DLLs that I am actively developing and would like to integrate logging into them as well. Ideally all the logging from these DLLs will be routed into the main application log - but I can't figure out how to do that using Pantheios. I can have them log to their own files but I can't figure out how to attach them to the main application log.
Any ideas?
Related
I suddenly have to support a Classic ASP web app (yes, I know it's older than dirt).
I am using VS2017 to attach a debugger and debug it. When I debug the code I notice that the code appears to depend on the following variable being set
Request.ServerVariables("HTTP_EMPID")
and I don't see where this is set anywhere. Usually, I expect server variables to be read only and provided by IIS but this looks like a custom variable and is not in this list
https://www.w3schools.com/asp/coll_servervariables.asp
I don't have access to the web server. Is it somehow possible to configure a web site to populate this variable perhaps via an applet or some other means? If I could trace debug this code this would help me tremendously and this is one obstacle.
looking for some advice here on developing a common logging environment for a NuGet package.
I've currently got a private NuGet package created from a C# library that works perfectly for local console apps and as such was written to log to the Windows event log.
Now I want to be able to use that package in an Azure function but of course Azure uses a different logging mechanism.
Any advice on how to create a logging overlay that allows the library to be compiled on my local PC in Visual Studio but also support logging in Azure if the package is used there?
Cheers,
Dave
I believe you are looking for the Microsoft.Extensions.Logging namespace and interface. This interface is used extensively across azure services, .Net 4+ and .Net Core. If you look for related nuget packages you will find multiple implementations for different logging scenarios and tools, including native sinks like event logs, functions, console as well as custom sinks like Splunk and Serilog.
If you separate your logging implementation from your application/package code and implement Microsoft.Extensions.Logging and adhere to the interface, then your logging interface can be easily plumbed in to many supported sinks, including functions.
A previous answer of mine provides an earlier, more manual approach to this problem. See here.
I am using EventSource to log events in my library. That library is cross platform meaning it could be used by linux/mac users. I know how EventSource works on windows. Users can view default logs using tools like PerfView or Logman tool or implement EventListener class to direct logs to a different location.
But EventListener class is not available on mono. Where are the events logged by EventSource by default on linux/mac? Are there any tools available to view them?
Please let me know if more details are needed.
Just look at source code for EventLog here. There you will see there are 3 event log implementations on mono:
Windows event log (obviously works only on windows)
Local file even log (logs to local file)
Null event log - just drops everything you log.
How it chooses one? It looks at environment variable MONO_EVENTLOG_TYPE. If it's not present, and you are not on windows - null even log is chosen (which should answer your question where your logs will go by default).
If variable is present and equals "local" - it will log to local file. If you want to know where exactly it will put those files, look here. You will see default path for such logs on linux is "/var/lib/mono/eventlog".
All in all - if you develop cross-platform library, consider using something other than pure EventLog (some library like log4net is already fine, and configurable, and can log to EventLog too, among other options). As noted in comments - you indeed can set that environment variable for current process with SetEnvironmentVariable, but still other concerns remain valid.
EDIT: Sorry I was a bit confused and answered quite another question :) Now I see you mean ETW. So ETW is Event Tracing for Windows and I doubt it is implemented in mono. In fact you see yourself with a link you provided in comments that EventSource class is just a stub which does nothing. Mono has quite a lot of such stubs so that your .NET code can compile and run, even if some functionality is not implemented. So answer to your question is - ETW is not supported on mono. You can get around that by checking on which platform do you run in your EventSource implementation, and if you run on mono - don't use WriteEvent but instead log to another place (log4net file as an example).
I have a largish application that currently uses log4cxx as its logging system. However, these appears to be a dead project, and I cannot get it to work with Visual Studio 2013. As such, I am looking to move to log4net
Our project is a mixed C+/C# project, using .net 3.5, and the logging is pretty simple
What is the best way to handle this migration. Any particular problems that people would expect to see, any required changes to config files, etc.
Also, is there a simple tutorial on how to use log4net. Unless I'm misreading it, it appears to be a case of reading the source examples until you figure it out.
I'm using log4net logging in my software that consists of several applications.
I want to have one common library for this.
I created a library and put it in the conficuration file. In AssemblyInfo.cs placed attribute:
log4net.Config.XmlConfigurator(ConfigFile = #"c:\logging.xml", Watch = true)
It work for windows service, but in dosn't work for asp.net application.
It work in asp.net if delete attribute from common library and put in into global.asax. However, this leads to that section of the log4net configuration must be made in the windows service.
There is also a business process which causes our library through the
remouting. I want the logging was carried out there too.
Is there way around this?
In my opinion the library should not define where the configuration file is found. Maybe a better idea would be to have a helper method that allows you to configure log4net quickly; that method would take an optional parameter for the config file path and would try to load the configuration file from the specified path first and if that does not work fallback to some maybe the current folder, the application folder or even the web / app.config.
If you insist that it must be an absolute path then you need to give the IIS Application Pool user read access to this file. This way the configuration by attribute should work for services and ASP.Net applications. I do not understand what you mean by "remounting".