Protobuf-net - Did I initialize that list or not?

Protobuf-net is a very great binary serializer for .NET. I use it heavily on my project (memory, file, and over-the-wire serialization).

One of the confusions I recently had is that after I initialized a List, I assumed that it will be serialized into the stream. However, having a zero-length List, it always return null whenever protobuf deserializes the stream. I had seen some developers do a null checking or implement null-coalescing operator operations after they deserialize the stream and those null checking are scattered through-out the code (which violates the DRY principle and is ugly).

One very simple work-around for this is to provide a standard constructor and initialize the List on that constructor. Here is a sample unit test code which demonstrates that.

Special thanks to the protobuf-net author: Marc Gravell

My C# Naming Conventions

I would like to share the naming conventions that I am using for C#. Link

I use this as a guideline to be able to make my code more readable (especially for big projects) and to be able to identify the type of variable or method in one glance.

Moq (and primitive mocking) Demo

Here is a simple demonstration of using Moq and using a primitive mocking approach.  Link


The 1st approach (using Moq), takes a bit of a learning curve, but it is worth doing it.

The 2nd approach is easier, but at the expense of creating additional dummy class/es.

JSON reading and writing in C#

Here is a very simple example of JSON operation for C#. Link

C# code for E-Gizmo's RFID using Observer Pattern

Here is a console application to demonstrate the E-Gizmo's RFID. The code is written in C# / .NET 4.5. This uses simple observer pattern with one subscriber. The code could still be extended to support many subscribers.

Music: My version of Floyd Rose Tremolo Stopper for my Craftsman EG-95 guitar

Just now, I tried to create a Floyd Rose Tremolo stopper from another cheap floyd rose. I used the saddle/intonation screw and i turned out to be working pretty well. :)  No vibrations nor any problems after the modifications. :)

.NET CF / Windows CE Threading

Lately, I was baffled by a problem in my current Windows CE/ Windows Mobile project. The scenario is quite simple:

• I have a Keydown event on my form.
• On the keydown event handler, I need to do some task which just takes around 500msec to complete.
• On that keydown event handler, I placed a C# lock construct to block the incoming keypresses (and with some Application.Doevents to pump the message queue).
• Then I did some destructive testing. The outcome: If I press a lot of key within the 500msec, the application throws an StackOverflowException.
• Next, I used the Monitor.TryEnter/Monitor.Exit so no blocking will occur. I did the same test. The result: StackOverflowException.

It seems to me that the code is being executed again despite it is inside a lock construct. Normally, what I will do on a PC-based .NET application is to set the control's Enabled property to False, then issue an Application.DoEvents before enabling the property again. Doing this in .NET Compact Framework with a device that is not as fast a PC,  gives an undesirable aesthetic effect. Our device's screen painting is quite slow and doing this method grays out the entire form then back to normal again.

Going back to topic and to illustrate my point:

• I created a sample Windows Form Application. Source code
• There is a keydown event. This must display an incrementing number, have a delay of 750msec, increment the counter, then exit the handler.
• The expected behavior is to display incrementing number each time a key is pressed.

I did an experiment using lock (See the function LockingUsingDotNetLock on the source code). If I press keys within 750msec, the textbox will display the same numbers! It must be incrementing! What happened? I would like to admit that I missed a crucial information regarding C# lock. Just yesterday, I researched more about it (Google, MSDN, StackOverflow.com) and found out that C# lock is re-entrant. It will block access to other threads but it can be acquired again and again by the same thread (Re-entrant Mutex).

Now I know the problem. What will be the solution? Here are the solutions that I could think of as of the moment:

• Using ordinary volatile variable for the locking (See the function LockingUsingVolatileVariable on the source code). It is a very simple solution. If I press keys, only one key will register and the incrementing number will display correctly. Most of the time, this is the behavior that we need.
• Using lock, but this time, we spawn another thread inside the handler (See the function LockingUsingDotNetLockOnAnotherThread on the source code). If I press keys, the key's will queue up, and will display incrementing numbers with respect to the 750msec delay in the code.
• Using Monitor.TryEnter and spawn another thread inside the handler (See the function LockingUsingTryMonitorOnAnotherThread on the source code). This will have the same behavior with Solution #1.