SmartConnector Forum
Schneider Electric support forum about SmartConnector applications for integration of other building management systems (BMS) into EcoStruxure Building Operation.
Link copied. Please paste this link to share this article on your social media post.
In earlier versions of SC, the user would configure the location of the log files in the Mongoose.Service.exe.config file (or in the app.config file for a developer). Since version 2.1.83, the log file is automatically located in the C:\ProgramData\SmartConnector\Logs folder for the installed windows service.
Where is the log file stored for a developer, or is there some configuration necessary? My processor is writing entries to a log (by calling Logger.LogInfo, Logger.LogError, etc.), but nothing is showing up in the logs in the above folder.
Thanks.
Link copied. Please paste this link to share this article on your social media post.
You are correct. Prior to the 2.1 release, the logging framework used in SmartConnector was highly configurable via the app.config file for the service executable. During the extensive cyber-security testing which SmartConnector underwent prior to the 2.1 release, it was determined that this highly configurable approach was a potential security vulnerability. As a result, we decided to limit the amount of configuration customization available to the end user and control configuration programmatically. One of these limitations was to force logging to a single location where access could be secured using Windows security policies.
Under the covers SxL.Common.Logger class uses a singleton pattern where the actual log writer class is lazily instantiated the first time it is needed. This lazy instantiation is when configuration mentioned above occurs. One of the configuration steps is to set the target location. This is done based on the value of the runtime AppDomain.CurrentDomain.GetData("DataDirectory") value. Since SxL.Common is a very low level assembly, it has no “app” knowledge so it assumes that something has already set this. If nothing has (like in your case) the value is null and no logging occurs.
During normal SmartConnector service runtime this is obviously handled for you. However in a Unit Test environment you do need to intercede and set this manually. The easiest way to accomplish this, is to create a reference to the Mongoose.Service.exe from your Unit Test assembly and then call Mongoose.InitDataDirectory() in your FixtureStartup method (similar to calling InitIoC for database access).
Additionally, there is a NuGet package available for unit testing of Processor extensions. If you install the Mongoose.Process.Test NuGet and add the IMongooseFixture interface to any Unit Test fixture class you will have access to several extension methods for running unit tests. One of these is EnsureLoggingEnabled. This method will call InitDataDirectory and ensure that a “Testing” LogCategory is present and enabled for logging. This way, you can log “Testing” entries which wouldn’t affect production code. These can be in your production Processor itself or in the Unit Test fixture or both.
If you use the above methods, the log files will always be located in %SYSTEMDRIVE%\ProgramData\SmartConnector\Logs.
Link copied. Please paste this link to share this article on your social media post.
You are correct. Prior to the 2.1 release, the logging framework used in SmartConnector was highly configurable via the app.config file for the service executable. During the extensive cyber-security testing which SmartConnector underwent prior to the 2.1 release, it was determined that this highly configurable approach was a potential security vulnerability. As a result, we decided to limit the amount of configuration customization available to the end user and control configuration programmatically. One of these limitations was to force logging to a single location where access could be secured using Windows security policies.
Under the covers SxL.Common.Logger class uses a singleton pattern where the actual log writer class is lazily instantiated the first time it is needed. This lazy instantiation is when configuration mentioned above occurs. One of the configuration steps is to set the target location. This is done based on the value of the runtime AppDomain.CurrentDomain.GetData("DataDirectory") value. Since SxL.Common is a very low level assembly, it has no “app” knowledge so it assumes that something has already set this. If nothing has (like in your case) the value is null and no logging occurs.
During normal SmartConnector service runtime this is obviously handled for you. However in a Unit Test environment you do need to intercede and set this manually. The easiest way to accomplish this, is to create a reference to the Mongoose.Service.exe from your Unit Test assembly and then call Mongoose.InitDataDirectory() in your FixtureStartup method (similar to calling InitIoC for database access).
Additionally, there is a NuGet package available for unit testing of Processor extensions. If you install the Mongoose.Process.Test NuGet and add the IMongooseFixture interface to any Unit Test fixture class you will have access to several extension methods for running unit tests. One of these is EnsureLoggingEnabled. This method will call InitDataDirectory and ensure that a “Testing” LogCategory is present and enabled for logging. This way, you can log “Testing” entries which wouldn’t affect production code. These can be in your production Processor itself or in the Unit Test fixture or both.
If you use the above methods, the log files will always be located in %SYSTEMDRIVE%\ProgramData\SmartConnector\Logs.
Link copied. Please paste this link to share this article on your social media post.
Thanks. I was able to get logging to work by explicitly calling the InitDataDirectory method in the FixtureStartup method as you indicated. The full call was Mongoose.Service.Mongoose.InitDataDirectory.
But I wasn't able to get the NuGet option to work. I believe that the IMongooseFixture interface and extension methods are in the Mongoose.Test project, not the Mongoose.Process.Test project. So, they're not available via NuGet.
Link copied. Please paste this link to share this article on your social media post.
You're correct about IMongooseFixture not being available. I'll look into moving those extension methods into the public NuGet so the would be available to everyone. I think there is value there for the developer community at large.
Thanks for the feedback.
Create your free account or log in to subscribe to the board - and gain access to more than 10,000+ support articles along with insights from experts and peers.