Write to NUnit's Text Output tab from unmanaged code - windows

I have an NUnit test dll written in C++/CLI, which tests some unmanaged code. Is there a way to print log messages to NUnit's Text Output tab from the unmanaged code? I tried OutputDebugString and cout << "blah", but no cigar.
NUnit version: 2.5.10
I know this might be bad practice, but let me do it just once, ok? :P

There isn't any way to my knowledge to capture this output in the output tab.
However, there is an undocumented option, /console, to the NUnit GUI runner that creates a separate console on which any unmanaged output to standard output is displayed. It may also capture standard error - I wrote it a long time ago and don't remember.

Related

pyCharm Debugging: skip framework code

Is there a way to tell pyCharm that it should skip framework code? The debugger should skip all lines which are not from me.
In my case it is very easy to tell which code I want to debug and which not:
Code in virtualenv lib should be skipped
Code in virtualenv src should be debugged.
If I press F7 (Step Into) it should skip all lines which are not from my code base.
[Update May 2015: introduced in PyCharm 4.5]
There are two new features now, one of which is the one you asked for, but I mention the other one as well because it is topically very close.
From the 4.5 release notes:
Step into My Code
Stay focused on your code by telling the debugger to step only through your project code, as opposed to stepping through the library sources.
[...]
Ignore Library Files
The debugger is improved with the new 'Ignore library files' option. Use it to have the debugger stop inside your code in case the exception is raised in a library module, instead of stopping inside the library code.
[Update after learning about blackboxing libraries in debugging]
In this answer it is mentioned that you can add the modules to ignore into "the dict DONT_TRACE in /helpers/pydev/pydevd.py"
And there is an open issue on the issue tracker.
[original answer]
It is not possible to skip code like that, but you can flexibly switch between walking through the code line by line and making bigger jumps in a running debug session by simply adding another breakpoint (while debugging - break points can be changed in a running debug session) at the position after the library code you want to skip and press 'Resume Program' in the Debugger. The library code is skipped and you are back in your code.
You might also want to use conditional breakpoints to make sure that the program breaks into the debugger exactly when the program is in the state that you desire: right click on a breakpoint and enter a condition that has to evaluate to True in the context of that line.

Remove third party debug messages from output in Visual Studio 2010

I am using a third party library in a project and it spams the Output console with its own messages. I have absolutely no desire to see the messages when I'm debugging my code. Is there any way to tell VS to not display the outside libraries messages and only display mine?
You cannot filter the output debug messages, but in general there is way to tell the libraries not to dump messages to the output debug window (compile time define / runtime call / outer configuration tool like netsh.exe).

Visual-Studio Output window events time

When i use Trace methods (.NET) to see what happening in my code i need to add time to output string in most cases. Thats allow me to see when actually output string was printed. Is there any way to customize IDE (probably, some options or extensions) so time will be added automatically?
There is a set of Visual Studio extensions called Productivity Power Tools available for VS2010 right the way to VS2017. One of the features from 2013 onwards is "Timestamp Margin" which adds a timestamp at the start of each line in the Debug Output Window only. Features in the extension can be enabled individually.
If you're using VS2017, there is also a much more lightweight, standalone extension with just the one feature.
Finally, there is also a much fancier extension called VSColorOutput which colour codes the Debug Output Window based on regular expressions. Optionally it will add timestamps as well.
At the time of writing all of these options work only on the Debug output.
I know this question is tagged with VS2010 but I think anyone reading this still using that version will be in the minority.
Depending on which trace methods you are using, and how picky you are about format, you may not need to write additional code.
You can set the Timestamp or DateTime TraceOption flag on your trace listener's TraceOutputOptions property. You can set that property programmatically or via your configuration file.
The DateTime flag with the default trace listener gives you something that looks like this:
prog1.vshost.exe Information: 0 : Hello world
DateTime=2011-03-12T22:22:55.6902126Z
while Timestamp looks like this:
prog1.vshost.exe Information: 0 : Hello world
Timestamp=991294310087
See the remarks section of the TraceOutputOptions documentation for caveats - e.g., the flags don't affect Write() and WriteLine().
That requires code. In your program. It isn't hard code, works without the debugger too. Which tends to be important if you care about time.
Look at, say, log4net to get this added automatically.
You should be able to write a little function like wchar_t * GetCurrTimestamp() and stick it in your TRACE macro calls, like this:
TRACE(_T("%s: My debug message.\r\n"), GetCurrTimestamp() );

Get the callstack(s) when a kernel32.dll function is called

I have a process that changes its current directory, and I would like to know when and where it happens. How could I do that?
I tried setting a breakpoint in SetCurrentDirectoryA/SetCurrentDirectoryW with Visual Studio, but it does not work.
Are you debugging one of your own programs, or one that you don't have the source code for? The Visual Studio debugger isn't very friendly with regards to debugging no-source applications; in that case, I would recommend WinDbg or OllyDbg - or even skipping the debugger and write an instrumented logger using EasyHook.
EDIT:
Try setting a breakpoint at {,,kernel32.dll}_SetCurrentDirectoryA#4 - peculiar syntax and requires decorated names. Haven't tried it myself, but found it here. Google keywords: "visual studio breakpoint api" :)
You need to attach/debug the process using native code. If you by mistake are debugging using managed code you will not hit those breakpoints.
Your program may be changing directories using the msvcrt functions.
You should try placing breakpoints on these functions as well:
_chdir
_chdrive

Issue with compiling a program into an EXE, VB 6

I have recently edited a fellow student's data collection software to my specifications. The program works fine when I run within Visual Basic 6, however ideally I would like to compile the program into an .exe file so I can run it from any PC. However, when I select the option to turn it into an exe, I get the following error while its compiling:
Compile Error: Sub or Function not defined.
I was curious why my program will run from within Visual Basic, but can't compile into an exe. Any fixes/suggestions would be greatly appreciated!
You must just be running the app in the IDE by using Start (F5) - this does not do a full compile so won't catch all compile errors. I suggest you always use Start With Full Compile (Ctrl+F5) - then it will show you where the errors are.
You can create a custom control bar button to do the Start With Full Compile - saves typing CTRL+F5 all the time.
at the begining of every file, write "option explicit". This changes vb behavior from weak typed to strong typed.
What this means is that when you put a string into an integer, then the vb will tell you right away, or at least when you press "run". In a weak typed mode, the program will run until it encounters a fault, like "Sub or Function not defined" then crash.
When you compile into an "exe", vb needs to do extra sanity checks much like "option explicit" would do. This is why you don't see the problem while normal execution. It is still there, lurking, but you probably don't execute the problematic line.
It is very important that you use this keyword in every vb source file you have, otherwise you'll see problems like this all the time.
It allows you to run the program even though it won't compile due to the Compile On Demand feature the IDE supports. As noted in other posts you can CTRL-F5 to do a full compile, or you can go into Options --> General and turn off Compile On Demand...(saves a lot of CTRL-F5s)

Resources