Ya’ll know how when we use Debug.Print, if we switch to release mode, the command still works, even though it should not… well, I was looking through the Debug.cs class and saw this:
public static class Trace
{
[System.Diagnostics.ConditionalAttribute("TINYCLR_TRACE")]
static public void Print(string text)
{
Debug.Print(text);
}
}
public static class Debug
{
[MethodImplAttribute(MethodImplOptions.InternalCall)]
extern static public void Print(string text);
//--//
This makes perfect sense to me now. Years ago, I stumbled upon the fact that Trace.Print was removed from the release if you excluded the TINYCLR_TRACE conditional argument. Looking at this source completely explains that now! Now if you look below the Trace class, the Debug.Print should have an additional attribute of " [System.Diagnostics.ConditionalAttribute(“DEBUG”)]" but it has none! I think this is why release mode gets compiled with print statements!
I usually test these hypotheses before posting, but I have a long running wifi test that I don’t want to interrupt. I wanted to post it before my mind wandered to something else.
I have created various wrapper classes before to work around this, but fixing this would eliminate all of that. And my experience tells me that this can save a lot of program space!
Also, you can see how trivial it would be to add the WriteLine method (just like in regular .NET) so that there is more consistency between the MF and the Jumbo version. And you don’t have to remove Print, just keep that for backward compatibility…
I can confirm what you have seen.
I saw the same in code and I have tested it.
Debug.Pring is active in release mode as well in NETMF.
If Win.NET it’s excluded in release build.
public static class DebugInfo
{
public static void Print(string str)
{
#if DEBUG
Debug.Print(str);
#endif
}
}
Unfortunately I don’t know if all DebugInfo.Print are removed from the app when not in DEBUG mode but at least I don’t fill the USB debug port with unusefull data.
Ok, I just rebuilt my Microframework PK with this change, and it works perfectly! After closer inspection, I found that this change gets incorporated into the Microsoft.SPOT.Native.dll. So, no firmware change is needed. I would strongly encourage GHI to include this simple change in the coming release that includes QFE1.
As you can see I was shot down because “Yes, it is the only way to dump onto teh serial/usb/sockt port from the app level.”
Then the issue was closed… I actually disagree with that response though. If they need a method that outputs in Release mode they should add a method called “Console.WriteLine” and make “Debug.Print” removed at compile time. AND, for goodness sakes, there is NO excuse for all the missing intellisense comments in .NET MF. When I make changes like this, I just go to the PC .NET Framework and grab that comment. And don’t get me started on the generic Exception types!
Oh well. Hey, it’s all open source, so we can do whatever we want right!? I already fixed this for myself. It’s really all for the newbies that have to figure this out. This is really trivial to fix.
I’d suggest raising it again, reference the other items, propose a patch (gives others who want to go this way a head start) and see how the new team listens/reacts
I’d support that. Please add another CodePlex issue.
To minimize maintenance efforts, confusion and later integration problems with new Microsoft releases, I’d rather not have such changes in some distributions and not in others (e.g. GHI vs. Mountaineer).
For the Mountaineer firmware, we try to avoid changing any portable files wherever possible. It’s not always possible, but we’d rather focus on feeding unavoidable changes back to Microsoft’s porting kit rather than to manage a growing flea circus of small changes to the porting kit.
I wholeheartedly agree Cuno, the least amount of fragmentation on the core porting kit components the better. Sure, to address issues quicker all users may need to incorporate that change for some time themselves, but ultimately the ecosystem improves by addressing issues and by making things consistent across platforms.
