How to change BitFactory.Logging Default Folder Path?

[sesa180961_brid]

When using EWS.Client (2.2.108.0) and BitFactory.Logging (1.5.2.0), I see a few options (in the config file) to add path to where the logs will be written to.

An example is:

<compositeLogger name="debugLoggers">

        <rollingDateFileLoggers>

          <rollingDateFileLogger name="debugFileLogger" isInsistent="true" formattedFileName="C:\Schneider Electric\App\Logs\EWS\Debug_{timestamp:MM-dd-yy}.log" />

        </rollingDateFileLoggers>

      </compositeLogger>

But when I run the program, the logs are not being written in the folder specified above. They are always written to the folder where the program executable is located. Is this a default setup?

Is there a way to change this path?

[JeffBowman]

Hi Maneesh,

I think you posted this in the wrong forum, can you move this question to the SmartConnector developer forum?

However, as a quick answer BitFactory.Logging is deprecated anyways and is not used anymore.

-Jeff

[sesa180908_brid · Accepted solution]

Jeff is correct.  During 2.1 cyber security review, it was deemed that a configurable log destination folder was a vulnerability.  In that version, we switched from BitFactory.Logging to NLog as the library used in SmartConnector. 

The Logs are always found in the "%PROGRAMDATA%\SmartConnector\Logs" folder.

[sesa180961_brid]

I am not using SmartConnector in this project. Its only the EwsClient library.

[sesa180908_brid]

Same goes for that scenario. 

[sesa180961_brid]

Is there a way to log only Error logs instead of info, status, debug and error logs?

The customer does not want all the logs and the file size grows very soon.

[sesa180908_brid]

The short answer is "Yes".  That said, the coupling between the components of SmartConnector is becoming more the norm than the exception so "buyer beware".  It's advised that you use the framework as designed for future projects.  But here is what you need to do.

Logging in SmartConnector (and by extension EwsClient) is provided by the SxL.Logger Singleton class.  This class wraps up NLog.Logger adding in ambient filtering based on logging level and category.  The logic for filtering is provided by LoggingFilter (another Singleton).  Fortunately, it uses a "Provider" property which is based on the ILoggerFilterProvider interface.  So to take control over what get's logged, you would need to do something like this:

    /// <summary>
        /// Code that runs once when your "app" starts
        /// </summary>
        private void StartUpCode()
        {
            // 1. Set the data directory (here is where you could alter the log destination folder)
            AppDomain.CurrentDomain.SetData("DataDirectory", Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData), "SmartConnector"));
            // 2. Override the default Logging Filter Provider with your own.
            LoggerFilter.Instance.Provider = new CustomLoggingFilterProvider();
            // Use logging as you always would.
            Logger.LogDebug("My Category", "Hello World");
        }
        private class CustomLoggingFilterProvider : ILoggerFilterProvider
        {
            public bool AllowLogging(string category, LoggingLevel level)
            {
                return level >= MaximumLoggingLevel;
            }
            public LoggingLevel MaximumLoggingLevel
            {
                get
                {
                    return LoggingLevel.Error;
                }
            }
            public void Refresh()
            {
                // Intentionally empty
            }
        }