The Moth

This is a repost. The content appeared orginaly here, but I thought it deserved a post on its own rather than being at the bottom of an off (the main) topic entry.

[..] a demo I saw Don Box deliver at Tech Ed 2001 (in VB6) and TechEd 2004 (in Word Macro). So, in case you aren't aware of it, here is some VB6 code that always gets a nice reaction:
1. New VB6 "Standard EXE"
2. Project->References. Add:
Common Language Runtime Execuion Engine (mscoree)
Common Language Runtime Library (mscorlib)
3. Double-click on the form to get the Form_Load method (event handler)
4. Type in there the following 5 lines of code

Dim crh As CorRuntimeHost

Dim ad As AppDomain

Dim oh As ObjectHandle

Dim o As Object

Stop

5. Run->Start. The IDE breaks so you are in the debugger. View->Immediate Window
6. In the Immediate Window, type the following (line by line hitting return, don't just copy/paste)

Set crh = New CorRuntimeHost

crh.Start

crh.CurrentDomain ad

Set oh = ad.CreateInstance("mscorlib", "System.Collections.Stack")

Set o = oh.Unwrap

o.Push "Rocks"

o.Push "NET "

o.Push "."

MsgBox o.Pop & o.Pop & o.Pop

That's it! You've just used a .NET Stack class in VB6 by hosting the runtime.

A great number of posts in the NETCF newsgroup are memory related. This is no surprise, given the constraints of devices (as opposed to the PC), and most posts somehow end with a variation on this tail question: "[...] is this a known memory leak with the CF?"

Given that there are plenty of CF resources to help you in this area, I thought I'd gather them up in a single place for future reference.

1. The first thing to do is make sure you are running the latest released CF version. Contrary to popular misconception, this is (today) CF 1.0 SP3. For CF version info (numbers, how to determine it, where to get it etc) please go here.

2. Doing the above is good regardless of anything else; the second thing to address is "Are you really having memory troubles?” Can you reproduce a sample where you get an OutOfMemoryException? If not, why do you think there is a memory leak! This is common to devs still new to the managed world, where resources are not reclaimed immediately after they have been used. A rule of thumb applies here: if an object you are using offers the Dispose method, call it when you have finished using the object.

3. So we've now reached the case where you can reproduce a sample that throws the OutOfMemoryException (or at the very least that is what your main app does). Before you start pointing fingers at the Garbage Collector, please understand how the GC works (note the significant differences compared to the Full Fx version i.e. not generational, code pitching etc). Once you've done that, understand some v1.0 issues and workarounds, including when to call GC.Collect

4. "Fine with all the theory, but how do I measure?" You have a number of options available (please use them):
- Call GC.GetTotalMemory(false)
- PInvoke GlobalMemoryStatus (FAQ 6.5)
- Monitor Perf Statistics/Counters (do follow the links from that blog entry)
- Device's control panel applet e.g. on WinCE emulator, Start->Settings->System look under the Memory tab for memory info and how to change the memory distribution (check out the FAQ on the WinCE memory division between Storage and Program memory)

5. For completeness, here is a link to an in-depth article on WinCE memory management. The main takeaway, if you are coming from a desktop background, is that each process in CE has a limit of 32MB virtual address space; so forget loading all those massive bitmaps in memory.

6. On very extremely rare occasions you may possibly observe a "Low Memory Dialog" rather than an OutOfMemoryException. This is the OOM dialog which shouldn't, but may, pop-up before a managed exception is thrown. That is an indication that you are stressing the system but, if you really want to, you can remove the OOM component from your device - assuming you have control of the image with Platform Builder (if you are in that situation, check out the SetOomEvent and registry entries).

7. Finally, if none of the links above take you to long documents with many numbers, go read Advanced Memory article on CF 2.0

I will not flood you with links like last time, but I must tell you that last week's winners have come back with killer posts; so revisit their blogs if you haven't already subscribed.

At the end of the first calendar week of 2005, why not download some tools (that I must admit not having played with yet)
-Check it out if you are working with process in WinCE and NETCF

-VS2005 Device Command Shell (a new tool that I bet will become very popular)

-Finally, subtle but important points about mixing operator overloading and inheritance.

Regular readers will recall the deployment feature for Smart Device projects that was cut after Beta 1. It has now been confirmed that the "Deploy to My Computer" feature will not be supported for RTM. However, there are some steps you can follow to get it working (it just won't be supported) and it is likely that in the future there will be a powertoy to do the steps for you.

If you want more details on the feature I am talking about, and more importantly want to follow the steps to get "Deploy to My Computer" working today with the November CTP, please visit ladybug.

Below is a copy of the steps (which I can confirm work... on my setup anyway:-).

This is courtesy of Kei Amos:

Enabling deployment of managed applications to the desktop rather than a device:

This is a great productivity enhancement for application development, when you deploy often.
Note: Applications that use device-specific apps will not run properly on the desktop, and controls will render as desktop controls.

INSTRUCTIONS
1. In Visual Studio select Tools/Options, and then select Device Tools/Devices from the tree.
2. In the top combo box, select the platform that you want to add desktop deployment to. You’ll need to do this for each platform you want to use.
3. Select one of the devices, (it doesn’t matter which one) and click the Save As… button. Save as “My Computer”. If you’ve already done this for a platform, you’ll need to save subsequent devices with slightly different names (like “My Computer2”)
4. Close VS and open your %USERPROFILE%\Local Settings\Application Data\Microsoft\CoreCon\1.0\conman_ds_platform.xsl file in a text editor.
5. Find the <DEVICE …> element corresponding to the device you created and add the node (i.e. search for “My Computer” to find the correct node.)
<PROPERTY ID="IsDesktopDevice" Name="IsDesktopDevice">true</PROPERTY>
Place it right after the first <PROPERTYCONTAINER> tag.
6. Save conman_ds_platform.xsl and restart VS.

Now when you deploy, you can select “My Computer” from the deploy dialog.

UPDATE: For Beta 2, also see this thread

As the sample I promised, I have written a visualizer for System.String. Given a string variable, it will show the bytes corresponding to that string based on the various encodings. The inspiration for it was the cry that a friend of mine got from their QA team recently regarding an app they have that "Doesn't work on a Chinese OS!".

To create it, we need a class library project that references Microsoft.VisualStudio.DebuggerVisualizers.dll and we add the following code:

1. Declare the attribute:

[assembly: System.Diagnostics.DebuggerVisualizer(

	typeof(EncodingVisualizer.StringBytes), 

	Target = typeof(System.String), 

	Description = "Encoding Viewer")]

The above is all you need to enable the new menu item when you hover over a string variable (or in the Autos window). In the IDE, the menu looks something like this. Note how VS2005 gives us out of the box the HTML, XML and TEXT visualisers.

2. The code that runs when the "Encoding Viewer" menuitem is clicked, is in your class:

using Microsoft.VisualStudio.DebuggerVisualizers;

namespace EncodingVisualizer {

    public class StringBytes : DialogDebuggerVisualizer {

        protected override void Show(IDialogVisualizerService windowService, 

	    IVisualizerObjectProvider objectProvider) {

	    string s = (string)objectProvider.GetObject();

	    frmStringBytes f = new frmStringBytes(s);

	    f.ShowDialog();

	}

    }

}

Naturally, you need a form frmStringBytes whose visual design looks like this; the constructor of the form does the work and is straightforward:

public frmStringBytes(string aString)

    : this() {

    txtExpression.Text = aString;



    string s;

    byte[] arr;

    arr = System.Text.Encoding.ASCII.GetBytes(aString);

    s = "ASCII   = " + BitConverter.ToString(arr);

    s += "\r\n\r\n";



    arr = System.Text.Encoding.Unicode.GetBytes(aString);

    s += "Unicode = " + BitConverter.ToString(arr);

    s += "\r\n\r\n";



    arr = System.Text.Encoding.Default.GetBytes(aString);

    s += "Default = " + BitConverter.ToString(arr) + "\r\n";



    // Do other encodings here e.g UTF7, UTF8, UTF32 etc



    txtValue.Text = s;

}

You may download the dll and place it in the right place as discussed before.

The latest Service Pack 3 for the .NET Compact Framework is now released as an MSI (via Tom Krueger). It was previously available as a QFE only.

For version number and full fix list please visit my previous announcement of the QFE release.

For history of NETCF version numbers and how to determine what version you are running see the wiki page.

Apart from Tracepoints (as hinted at the last sentence of that post), the most exciting debugging enhancement in Whidbey is the Debugger Visualizer support. If you are already familiar with VS2005 Debugger Visualizers, here you'll find what has changed with the latest Community Technology Preview (btw, the Dec is not the latest CTP from a framework version perspective, the Nov one is). If you are not familiar with the feature, I suggest you follow these links [ 1 , 2 , 3 , 4 ] and note the changes from previous versions detailed below:
1. The assembly reference must be to: Microsoft.VisualStudio.DebuggerVisualizers
2. The DebuggerVisualizer attribute ctor doesn't need the 3rd param i.e. delete the VisualizerUIType parameter as all visualizers are modal now.
3. Your class that implemented the Show method of IDebugVisualizer should now inherit from DialogDebugVisualizer and override the Show method; the signature for this now is:

void Show(IDialogVisualizerService, IVisualizerObjectProvider)

Of course, you need to imports/using System.Diagnostics and Microsoft.VisualStudio.DebuggerVisualizers; the location for visualizers (assemblies/dlls) is still the same: "My Documents\Visual Studio\Visualizers" or "[VS8]\Common7\Packages\Debugger\Visualizers"

That's all. If you didn't know about Debugger Visualisers and have downloaded the Nov CTP, follow the links at the top (and below), download their samples, make the appropriate changes and have fun!

Next time I'll implement a DebuggerVisualizer (not an Image Visualizer, which you can get here, here and here) so you have a complete sample to download.

-Like last week, it is a (almost) new blogger that headlines BLOTW, an MSFTie no less, Scott Holden. Read all 5 posts he makes in his first week including the one where we learn that the GC threshold in CF 2.0 changes from 750KB to 1MB.

-Not technical, but it caught my attention (and read it to the end following all links etc). Have a look and decide where you stand. I am not quite so sure...

-Some A-list bloggers claim that if you haven't posted for a month you are worthy of un-subscription, I don't buy that. Steven Pratscner's last post was over 4 months ago; had I unsubscribed I would have missed this most informative entry.

-How do you calculate the size of a directory?

-Not sure how you'll use this knowledge but if you like knowing what goes on under the covers when you set a breakpoint, this entry is for you.

-This BLOTW is the longest I've done, but still, I must point you to a time waster (via Tech Blender). I managed to write "THE MOTH" but the closest I got to my name was "DA IE MO H"

I don't like “pointing to myself”, but reflection is a good thing I guess. So, in chronological order, here are some of my favorite blog entries that I posted in 2004:

01. If you are changing thread priorities in your NETCF apps without being aware of these facts...good luck!

02. Everything about .NET Global Exception Handling is either in these 3 posts or in the links they point to: .NET 1.1, NETCF 1.0, .NET 2.0 (full & compact)

03. Whidbey's answer to UML class diagrams and where it falls short

04. So you are developing for both full & compact framework; are you doing it like this or like that?

05. Inter-Process Communication options with CF on WinCE; if it's not there, it doesn't exist

06. ALL links about serial comms (RS232) with .NET are here

07. VB2005 along with My brings Application Level events with a custom sub main. Use it *all* from C#

08. Control.Invoke today and tomorrow

09. More of a newsgroup support entry, but who says plain useful posts cannot be on my favorite list :-)

10. Generics in the Compact Framework (and not only)

11. BackgroundWorker today, tomorrow, full and compact frameworks: enough said

Thanks for reading... stay subscribed for an exciting 2005. As an aside, am I the only sad geek who associates the word "2005" with VS2005 ;-)

By now, all .NET developers know that their managed code (C#, VB.NET etc) gets compiled to Intermediate Language (IL) which itself, at runtime, gets Just-In-Time (JIT) compiled to native code. Here we'll look at some of the differences of the NET Compact Framework JIT engine compared to the desktop (full framework), as well as what CF 2.0 will change.

As a historical aside, the alpha (pre-RTM) version of the CF did not have a JIT compiler and instead IL was interpreted on the device. Since RTM (for CF version info please go here), the IL is JITted to native code on the device/target. This is done on a per method basis (like on the Full Fx). When a method is called, it is detected that there is no native code for the method, so IL is compiled into native code and executed; next time the method is called the native code gets executed, which means that the JIT performance penalty is only incurred once.

The major difference on the CF is that the native code is cached in the GC heap (i.e. in RAM) and is susceptible to "pitching" if a full GC occurs (for more detail on GC phases and pitching look there). In other words, the JITted native code can be thrown away under memory pressure, so next time a recompilation has to take place for any methods that were pitched. Do not confuse pitching methods with the actual type data structures (metadata), which are never pitched once loaded.

To obtain some numbers for your CF app, you should use the perf counters. In particular focus on: Bytes Jitted, Native Bytes Jitted, Number Of Methods Jitted, Bytes Pitched and Number Of Methods Pitched

Another difference in the same area is that ngen is not supported on the NETCF. So you cannot pre-compile your assemblies to native images.

Finally, note that the JITted code has a limit of 64K (native size, not managed). You wouldn't expect to hit that limit, but very large forms can break the rule in their auto-generated InitializeComponent method. The workaround is to split the method into smaller ones (at the expense of losing designer support).

CF 1.0 comes with two JIT compilers: sJIT and iJIT. The former is for ARM devices only and the latter is for all other CPU architectures (inc. SH3, MIPS, x86). SJIT takes slightly longer to compile IL to native code, but the resulting code is faster than what IJIT can produce (there is a detailed slide "Differencies between JITs" in this ppt, for anoraks :-)

CF 2.0 comes with a unified JIT, which is more performant and optimised than what we have today. Note that VS2005 will ship with ARM CPU Emulators and not x86 like today, so the emulation experience will be enhanced from a performance perspective too.

As you recall I have read all CF books, so I can tell you that both Building Solutions with the CF and CF Kick Start include short paragprahs on JITting. The NETCF bible dedicates a few pages on the JITted Code Pool / native image cache.

Happy New Year!