Use System.Diagnostics
to perform tracing. Though I have used log4net
and other logging solutions, I am only interested in getti
Two things:
1) Your workflow is most likely stopping due to exceptions because your .config file is not right. Note the changes:
<system.diagnostics>
<sources>
<source name="log" switchValue="All">
<listeners>
<add name="file" type="Microsoft.VisualBasic.Logging.FileLogTraceListener,
Microsoft.VisualBasic, Version=10.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
BaseFileName="gsf_workflows.txt"
DiskSpaceExhaustedBehavior="ThrowException"
Location="ExecutableDirectory"
MaxFileSize="81920000"
LogFileCreationSchedule="Daily"/>
</listeners>
</source>
</sources>
</system.diagnostics>
2) You've to flush the listeners, otherwise they won't be written. You can do it in two ways.
Explicitly call Flush method on your logger variable using again InvokeMethod activity.
OR
Turn on auto flush on config file:
<system.diagnostics>
<trace autoflush="true"/>
....
</system.diagnostics>
That being said, I don't know if you're aware of Workflow Tracking and Tracing capabilities. It looks a good fit for your needs. Check this answer for more links and examples.
FYI for everyone stumbling on this page..
FileLogTraceListener will not create folders if they are missing.
FileLogTraceListener will not bypass security, your process identity will need create+modify permissions on the target folder.
It's "bad form" to target the executable folder, this tends to change depending on the host (for example, when writing under IIS Express you aren't writing to the same location as DevEnv, nor the hosted web app.) One suggestion is that instead of "ExecutableLocation" you may want to opt for "Custom" and specify a particular path (such as X:\logfiles)
Writers flush to disk when their internal buffers fill, if memory serves me the default buffer size is 8KB. This is not a facet of trace listeners, but the underlying file stream it writes to.
Lastly, if you do not need the form and function of FileLogTraceListener, instead consider tracing to the EventLog (there is a listener for this) as this may be more accessible to other devs and non-devs (such as ops engineers, third party monitoring tools, etc.)