10 replies to this topic

[ChrisArndt]

Hi,
I've just started working thru The Internet of Things book. Everything works great, except Debug.Print does not show up back in my Output window.
I am getting a bunch of startup and shutdown messages in the Output window, but not my message. Breakpoints work fine; everything else seems to be OK.
I don't see any Solution Properties that seem like they would toggle Output -- the only property settings touched were to switch to USB deployment and setting the Device.

Thanks for any suggestions

[Stefan]

Hi ChrisArndt and welcome to the Netduino Community That's a strange issue! Do you see deployment in the output window? Do you use USB HID in your project code by any chance?

[CW2]

I've just started working thru The Internet of Things book. Everything works great, except Debug.Print does not show up back in my Output window.

Are you using Visual Studio C# Express? If yes, then Visual Studio automatically chooses the Debug configuration when you choose Start from the Debug menu and the Release configurations when you use the Build menu (Debug.Print(...) output is not visible in Release build). You'd need to select the Debug configuration, check "Show advanced build configurations" in Tools - Options if the configuration toolbar is not visible.

[Chris Walker]

Also, there's an option in Visual Studio to redirect Debug output (to the Console window I think). I didn't know that existed, but someone had that particular issue previously in another thread.

[CW2]

Also, there's an option in Visual Studio to redirect Debug output (to the Console window I think). I didn't know that existed, but someone had that particular issue previously in another thread.

Yep, that's right, it was discussed in Debug.Print stopped working - if the debug output appears in Immediate window, uncheck "Redirect all Output Window text to the Immediate Window" in Options dialog: Tools\Options\Debugging General.

[ChrisArndt]

Hi,
Sorry for the delay in my responding.

I seem to be getting other tracing sent to the Output window just fine. I have an excerpt below -- I would expect to see my Debug.Print msgs before "Done". Most of what I assume gets sent to Output is showing up, just not my stuff!

If I hook up MFDelpoy and Connect, it shows my Debug.Print.

If I set Breakpoints, I hit them and can inspect variables. So the debugger is fine.

There is nothing in the Immediate window, and the option to sent to Immediate is not checked.

Note: this is true with the Netduino Plus AND when I use the Emulator.

I am running Visual Studio 2010 Pro with SP1.

I am running on a 64bit Win7. I have the 64bit Netduino SDK installed. Anyone else running 64bit?? If I had to bet, I'd guess that there might be a problem with the 64bit SDK while the 32bit is OK.

Thanks for any ideas



...

'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'D:\Proj\Netduino\play\VoltageReader\VoltageReader\bin\Debug\le\VoltageReader.exe', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Secret Labs\Netduino SDK\Assemblies\v4.1\le\SecretLabs.NETMF.Hardware.NetduinoPlus.dll', Symbols loaded.
The thread '<No Name>' (0x2) has exited with code 0 (0x0).
Done.

Waiting for debug commands...

The thread '<No Name>' (0x1) has exited with code 0 (0x0).
The program '[9] Micro Framework application: Managed' has exited with code 0 (0x0).

[Chris Walker]

If you put a "Thread.Sleep(Timeout.Infinite);" at the end of your Main routine, does that help your Debug info show up? I'm just checking to make sure your Debug data has a chance to be printed before your app finishes. Shouldn't affect anything... BTW, the 64-bit and 32-bit SDKs are identical. The only difference is that the 32-bit version uses the 32-bit driver installation EXE to install the 32-bit driver (and vice-versa). Chris

[ChrisArndt]

If you put a "Thread.Sleep(Timeout.Infinite);" at the end of your Main routine, does that help your Debug info show up?

I'm just checking to make sure your Debug data has a chance to be printed before your app finishes. Shouldn't affect anything...

I tried
{Debug.Print("1"); Thread.Sleep(60000); Debug.Print("2")}
with a break on the second Print -- I hit the breakpoint, but never see the Print values.

Note: I see the same behavior with the Emulator - no output from Print. However, with MFDeploy I do see the Print output.

It's puzzling that the debugger seems fine -- I can set breakpoints, inspect variables -- but this one thing doesn't work.

[CW2]

However, with MFDeploy I do see the Print output.

Do you have MFDeploy connected all the time (using 'Connect' command)? If so, disconnect it and you should see Debug.Print output in Visual Studio (you may need to launch the application again in VS).

[Simon B]

Hi The output is in the immediate window! (Debug-->Windows-->Immediate) Ctrl+Alt+I I am getting EXACTLY the same issue: Running Netduino (standard) Visual Studio 2010 Pro, Sp1, Windows 7 64 bit edition. Getting exactly the same symptoms: debugger works fine, except that it doesn't seem to be getting the output from the Debug.print commands, I can also see the output in MFDeploy. When I attached to a running process on my netduino using the Visual Studio debugger, I briefly caught output from the program in the debug window, but only a few lines were written. My presumption was that the debugger itself is somehow blocking the messages. It was sheer chance I was looking through the available windows in debug mode, when I noticed the expected program output was appearing in the immediate window! The debugger must route the output to the immediate window (Maybe it is an option in Visual Studio somewhere) Hope this works for you too. Cheers, Simon.

[ChrisArndt]

I don't see any Debug.Print output in either Output or Immediate window, with Options ... "redirect to Immediate" on or off. The DLL start-up and shutdown messages appear in the Output window, but I suppose those are being generated locally by the bootstrapper. When I run MFDeploy, I get messages from the device. When I get a chance I will try this on some other machine. Until then, I'll be glad I have the debugger working, which is 98% of the problem. Thanks Everyone --- Chris