====== Visual Studio tips ======

===== Useful features for debugging =====

You probably already know classical features such as step-by-step execution (''Step Into'' or ''Step Over'' to enter or not in functions) with breakpoints (conditions, count, disabling etc), ''Watch'' window, etc.

But there are also a lot of other very useful features for debugging.

==== Navigation ====

  * ''Goto definition'' with a right-click on a type or function name
  * ''Call Browser | Show callers graph'' on a function name, to see all places of the project from where the function is called
  * ''Find all references'' on a symbol name, to get all places where it is used

==== Debugging a DLL ====

You can debug a DLL (with step-by-step execution, breakpoints and all the usual stuff) when it is launched by any program.

In ''Project Properties | Configuration Properties [ Debugging | Command'' you just have to put the path of the executable which will use your DLL.

Then, just put a breakpoint in your DLL source code, ''Start Debugging'' (F5) : it will launch the external program, and when your DLL will be used it will stop on the breakpoint.

Remark : the DLL that the executable use must be the same that the one generated by Visual Studio (you can't move or copy it). But it is simple to configure Visual Studio in order to generate the DLL in the path you want.

==== Attaching the debugger to a running process ====

If your program is used by another program and you want debug it in this context, you can.

With Visual Studio you can attach the debugger to a running process. Set ''Project Properties | Configuration Properties | Debugging | Attach'' to yes, and be sure that the ''Command'' field still refers to your executable.

Then, just put a breakpoint in your DLL source code, launch your program in any way you want, and after attach the debugger with ''Start Debugging'' (F5) : when your program will be used it will stop on the breakpoint.

==== Memory errors ====

In non-managed C++, Visual Studio uses special libraries in Debug mode, which add a lot of verifications when allocating or freeing memory, in order to detect some problems in your code. But unhappily it won't detect all errors, in particular access to non allocated memory areas.

There exist some tools which can do that, such as Purify for example, but I don't know any free tool for Windows (for Linux there is the excellent Valgrind).

The problem with these errors is that they are not deterministic, can occur anywhere anytime with no connection with the location of your error in the code.

An artisanal way to try to deal with that can be to allocate huge buffers of memory that you don't touch, but you compute checksums of theses buffers all along your code. If your code is wrong and write data outside allocated areas, it can modify these buffers and you will see it. Of course you're not sure at all it will detect your errors, but there is a chance.

There is a tool which automates this procedure with other stuff, called Memwatch, but this is still not foolproof.


===== Errors =====
==== Ambiguous symbol ====

When using threads (''System::Threading'') or something else you get errors like ''Ambiguous symbol'' for the ''IServiceProvider'' class in the ''servprov.h'' file that of course you never touched.

Just try to move the ''#include <windows.h>'' line BEFORE the ''System::Threading'' line for example (and not after or not at all).