This page explains how the product logs diagnostic information. Having this knowledge may help you diagnose any issues that you encounter during your use of the product.
Primary Destination - Data Store
The primary logging destination is the data store in which your designs reside. For data stores that support it - especially relational databases - a separate Logging schema is used to segregate the logging subsystem from the rest of the application data.
The primary data entity for logging is LogEntry. A LogEntry entity is written to the data store each time there is something deemed useful for diagnosis of the functioning of the application. Looking for new LogEntry entries is the primary way to discover more about what went wrong when you have an issue.
Fallback Destination - File
If logging to the data store fails, a fallback logging system is invoked. This involves appending entries to a file in the user's temporary data directory, to a file with the name DesiGen.LoggingFailures.txt. This is only used when logging to the primary data store fails, so it is uncommon for this file to even exist.
Bear in mind that this file is not cleaned up by the application. You may find very old entries from previous issues. Check the date and time of log entries in the file to make sure you are not distracted by outdated logging information.
During the first initialisation of the data store, the destination for logging does not exist, so it is normal for the primary logging subsystem to be unavailable. As a result, you may find entries in the fallback logging file from this initialisation process. Finding such information does not indicate a fault.
You can safely delete this file between runs of the application; it will be recreated if it does not exist.
In Windows, you can discover the location of your temp data directory by typing %TEMP% in the address bar of Windows Explorer. This location has changed as Windows has evolved; this used to be a location shared by all users, but is now a per-user location for better security and to avoid permissions problems.
Batching
Logging is batched; that is to say log entries may not be written immediately. This helps protect the data store from being overwhelmed in the event that a lot of logging is generated. However, there is a small risk that exception data could be lost in the event that the application crashes - especially if the process exits unexpectedly (such as if a general protection fault occurs.) Such problems are rare, so this is not expected to be a problem in everyday usage.
Privacy
The application does not share your logging information with DotNotStandard. If you contact us for support, please remember that we cannot see the logs that have been generated by default.
If you choose to share logs with us, please remove all personal or sensitive information from the log entries before sending them to us. Remember that email is inherently insecure, and sharing any personal or sensitive information via email or on publicly visible forums puts you at risk.