Notification or Alerts Framework for .NET C# Component - c#

I am looking for a Notification or Alerts framework that can be used in my application as a separate module, I can just use the features of the framework.Are there any good ones?.
I need frameworks that dont use to much dll from other vendors to do some jobs..just connected to .net framework dlls
notifcations like email as basic...

We are using log4net and have found great flexibility with it. We also have our own wrapper class which is used in all of our projects allowing us to use static methods for writing to the defined logs. Log4net comes with one dll, and of course our wrapper dll. It is easy to extend this for added functionality, our wrapper class now allows us to write to the windows event logs if/when needed.
There are plenty of examples of how to implement log4net, and it provides alot of ways to write/send log information:
http://logging.apache.org/log4net/release/config-examples.html
Example implementation of our wrapper:
Log.Error("Message", this);
Log.Error("Message", Exception, this);
Log.Error("Message", Exception, Type);
Log.Info("Message", this);
Log.Warn("Message", this);

Something like log4Net? or a messaging queue system, sks MSMQ

the microsoft enterprise logging module of the enterprise framework can be configured for your purpose. it supports a variety of channels including email and trace file. it can be reconfigured through a change in the configuration file of your app.

Related

What is the similar alternative for VB App.StartLogging and App.LogEvent in .Net C#?

I have to implement equivalent code of Visual Basic "App.StartLogging" and "App.LogEvent" in .NET C#.
App.StartLogging has the two parameters i.e. logTarget and logMode.
(https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/aa267165(v=vs.60))
I tried to find out same type of logging event in C#, but unfortunately not able to get.
System.
On some website, found like System.Diagnostics.EventLog is the alternate of App.StartLogging.
But not getting how ? App.StartLogging help to log data in local file, but i didn't get same behavior in System.Diagnostics.EventLog.
Can you please help me to solve my issue ?
There is no direct replacement, see https://www.vbmigration.com/resources/detmigratingfromvb6.aspx?Id=19,
A few App members are used to log application events - namely the LogMode and LogPath properties and the StartLogging and LogEvent methods. These members have no direct counterparts in the .NET Framework.
You will other have to write your equivalents, or pick a 3rd party logging tool that can do what you need.
For instance, nLog will allow you to log to both the file system and to the Event Viewer. Logging an event is simple you simply write to the log, the StartLogging event is going to be harder, I don’t know of any logging framework or library that creates an event for that, typically it starts before everything else.

How C# Dll accepts a logger interface and write to that log file

I have a C# Class library and I have to add logging. This class library is supposed to be used by multiple applications which having different logging mechanisms (like the NLog, Log4Net etc.). So I have to write Dll logs to the application's log file which they are using.
For that how can I implement a C# dll which is accepting a logger interface and to write to that log file.
There's a generic logging package Microsoft.Extensions.Logging.Abstractions that contains a set of simple ILogger interfaces. Most larger logging frameworks include out-of-the-box adapters for these interfaces. So it should be easy within the applications to wrap the logging to whichever logger that product uses.
You can find a simple example that should do most of what you need in this change

EventSource vs EventProvider

What are the main differences between the EventSource and EventProvider classes?
I understand both classes to be an event provider for ETW. If there aren't key differences in the two then what are the pros and cons.
I use the EventSource class simply because I found more examples/documentation online, and it seemed more straightforward to implement Channel support (writing to the default channels in the Event Viewer - admin, operational, analytic, and debug) because the EventRegister class automatically creates the manifest (described here).
In .NET 3.5 the EventProvider class was the only option for tracing using ETW. As the documentation states, you must create an Instrumentation Manifest file for your custom events, which describes the data types inside your messages. This is not such easy task, and it requires using separate tools, such as the Manifest Generator (ecmangen.exe). For more information, please see this post.
The EventSource class was added in .NET 4.5 and it introduced a simpler approach to writing your own events using ETW. Instead of creating these manifest files, they are automatically created for you, sparing the overhead.
I don't see any reason to use EventProvider given the above. As you mentioned, EventSource is more documented and much easier to use.

Capturing log output from library using Castle Core Logging

Currently depending on a library which utilizes the Castle.Core Logging abstraction. I've dug through both that library's docs, and Castle's, and can't seem to find clear explanation of how to capture log output to pipe to our logging framework of choice (NLog, in this instance). I've also dug through a few posts which touch on the topic, but dismissed as not applicable to this situation.
It should be noted that NLog works fine for the rest of the application. No errors seen in the internal logs. Just no output from this third party library.
I see the Castle.Core NLog integration, but that looks to be something to be utilized by the library depending on Castle, not one depending on the library.
So is it possible to capture log output from this library? Or do I need to reach out to the project for support?
If you own the process hosting the library, it is your responsibility to tell Castle.Core.Log which log provider to use.
Configure NLog in your application, then register NLog as the Castle Log Provider as explained in the documentation by calling
container.AddFacility<LoggingFacility>(f => f.LogUsing(LoggerImplementation.NLog) when creating your container
For your library (white) you should provide the logger factory by either setting it on the CoreAppXmlConfiguration instance, or supply your own subclass instance when initializing the library's Application object.
See https://github.com/TestStack/White/blob/master/src/TestStack.White/Configuration/CoreAppXmlConfiguration.cs#L53

Optional logging dependency for C# library?

I've been working on a library in C# and would like to offer capability for it automatically log all exceptions. Ideally, I'd like it to use log4net, thus allowing the client to configure the log however they like (i.e. they can redirect it to the EventLog or a database or what have you).
However, I would like to avoid having the logging dependency if they chose not to use the logging feature. Is this doable?
In other words, is there a way I can optionally have a log4net dependency, depending on what the client sets in config file?
The obvious answer is to use the System.Diagnostics.Trace subsystem with a custom TraceSource. That way you can set up, in the configuration file, any TraceListener you'd like, including log4net, EventLog, text files, Console, or XML files.
If you added a log4net TraceListener then the dependency would be loaded at runtime, and not compiled in. The Trace subsystem has become quite powerful since its inception, and I recommend you look into it.
You can use the tracing sub-system that is already built into .NET - it is configuration controlled.
I wouldn't add a dependency myself - simply emit messages through the tracing API - the client can decide how to log them if they so wish.
Personally I prefer the Log4Net API to that provided by System.Diagnostics.Trace.
So I have my own abstraction layer that uses a provider-model design pattern, and exposes an API similar to log4net. I can then plug in a log4net provider, but am free to replace it with a different provider (e.g. System.Diagnostics.Trace; EntLib) in the future.
The implementation is very similar to this one.
By doing this, applications have no direct dependency on the underlying logging provider, and you can easily switch to a different provider if you (or your customers) have other preferences.

Categories

Resources