I've got a fresh install of the VS plugin and the Debug tool.  Generally works fine except the breakpoints never hit.  Config details below.

I've got a simple Blink type sketch with enough Serial trace to ensure that the absolute latest version is being uploaded on every trial.  VM and Debug tool downloaded moments ago.  I can set breakpoints in the Debug tool but they never 'hit'.

VS Build config is "Debug".  Simple breakpoints set by clicking left margin of source appear normal and are listed in the VS Debug Breakpoints window.  Right click on breakpoint shows expected context menu - Condition, Hit Count, etc.  No special conditions or trace set on any of the breakpoints.

Click "Start Debugging" and the sketch compiles, uploads and runs, but never breaks.  Nothing in Output, Serial, or Immediate windows other than normal build/upload messages.

Any help/pointers appreciated.  I'm new to this forum.  Apologies if I've missed something obvious.

  - Evan

Configuration:
Windows 7 on 64bit AMD Quad Core
Visual Studio 2008 - V9.0.30729.1 SP
Visual Micro for Arduino - 12.10.2601
Visual Micro Debug Tools etc. - 12.10.2403
Arduino Nano V3 clone

Considerable progress!

I had indeed missed the significance of setting Micro Debug to "Full", not to mention tweaking Local Port, Remote Transport, et al.  Tracepoints are now working fine with messages, timestamps, variables, Min/Max, etc.

I'm taking a couple hours break to let my keyboard cool off and will then have a try at the full stop breakpoints.

Hopefully Constructive Feedback:  You might test the waters WRT your use of the term "Breakpoint".  I've been using VS since the primordial QuickC days, and before that endured many many years of assembler.  I therefore expected "Breakpoint" to mean the traditional Full Stop and then Poke Around action, rather than the flyby 'Tracepoints' which appear to be the design point of the Debug Tool.  This is not to say that I'm necessarily right - there certainly aren't many like me left around anymore - but setting expectations correctly is a huge part of keeping support costs under control.

Anyway, grateful thanks for the prompt and helpful response.

  - Evan

Your point is well taken that debugging MCU applications is quite a bit different than building a traditional accounting package.  And there are certainly many more Ardo programmers in your customer audience than Grizzled Old Timer's.  Perhaps it's best to leave it on a Least Surprise basis, or possibly Least Physical Damage.

And step-by-step descriptions of various scenarios will get even the GOT's past the teething problems.

Thanks again.  You've given us a marvelous set of tools.

  - Evan

ps: One question. 

When you view the project properties tool window can you see the descriptions of each property in the tip at the bottom of the window?

If not then you will see a horizontal bar below the properties that can be dragged upwards to give the tips area a reasonable size. 

I though the first job might be to make the tips more useful but not if they aren't obviously visible for most?

Thanks, I will try to include images of them when I make examples and improve the docs. 

This might make it more obvious but the intention is also move them and a lot of other settings to the "Micro Explorer". 

It will be easier to have a more obvious tip system in the explorer and I find the properties window a pain because when we click into source code the properties jump from project to that of the source file.

So, it would be nice to have the option to have the project properties on-screen all the time (or not) +The source file properties are not useful.