Hi,
I found an entry from 2009 that says the answer is no.
Checking in 2017.
Thanks!

Hi,

Nothing has changed and is unlikely to change. As always, you could roll out your own PrintDebug that prints to file. Make a class that contains it static and then to call your PrintDebug(string text, string path) you'd only have to include a using statement.

CODE:
Please log in to see this code.

If I run this code, I only get a message box, but not an output file with the name "test.txt". Am I missing something?

No. That sample code in post #2 is missing the writing to file logic. All it does is show a popup box. Topic starter is a veteran user with a Strategy code of 130K lines so for sure he didn't need more detail to get this elementary stuff done.

There are numerous examples to illustrate the creation of text files virtually eveywhere:

* Data | Exporting data out of WL6 to ASCII files

* Easiest way to read from and write to files
* DotNetPerls: TextWriter

QUOTE:
Topic starter is a veteran user with a Strategy code of 130K lines

If you have to debug 130K lines (holy cow), you might consider going hog wild by using the log4net facility that's built into Wealth-Lab. The catch is that you can't use the "primary appender" because WL uses that for its own internal error reporting. But what Post #8 in https://www.wealth-lab.com/Forum/Posts/Enhanced-Strategy-Log-request-33320 suggests is that you can create a "secondary appender" and associate your own private log file to that. If that works, then you can send your own debug lines to that secondary appender, which will append them to your own log file.

The log4net facility is its own application (included in WL). You can read about it here: https://www.codeproject.com/Articles/140911/log4net-Tutorial

I thought about using log4net myself, but my code base is less than 3K lines, and 75% of that is in "semi-completed" DLL library code. My problem is not debugging the code base itself, but trying to optimize and revise the model itself. In this case, it makes more sense to package the residuals of the model into an R dataset and sending that into R for further interactive analysis. From this off-line analysis, I can further enhance the existing trading model.

If one has to debug 130K code lines he's better off doing so in Visual Studio environment by any means.

QUOTE:
If one has to debug 130K code lines he's better off doing so in Visual Studio environment

I don't have any strategies with more than 400 lines of code. Trying to actively manipulate more lines than that isn't productive. All my strategies call "semi-completed" and debugged DLL library routines (about 2.5K lines) I created with Visual Studio. This is what Microsoft designed Visual Studio for--professional development.

Work smart, not hard.