XmlSerialization - why two runtime behaviour for class with read-only properties?

Following on from the previous blog post, and just to recap, there are at least two ways to write a class with read only property.

The old way is:

    [ Serializable ]
    public class PersonReadOnly {
        String m_Name;
        Int32 m_Age;

        public String Name {
            get{ return m_Name; }
        }
        public Int32 Age { 
            get{ return m_Age; }
        }

        public PersonReadOnly() {
        }

        public PersonReadOnly (String name, Int32 age) {
            this.m_Name = name;
            this.m_Age = age;
        }
    }

and the other way is to use private setter like this:

    [ Serializable ]
    public class PersonReadOnly1 {
        String m_Name;
        Int32 m_Age;

        public String Name {
            get{ return m_Name; }

            private set { m_Name = value; }
        }
        public Int32 Age { 
            get{ return m_Age; }

            private set { m_Age = value; }
        }

        public PersonReadOnly1() {
        }

        public PersonReadOnly1 (String name, Int32 age) {
            this.Name = name;
            this.Age = age;
        }
    }

These two classes functionally are the same. However, the XmlSerializer exhibits very different behaviour depending on how you write the class. This to me seem rather odd.

In the case of PersonReadOnly, there is no runtime exception, except that the state of the class, namely Name and Age, are not serialized as in agreement with the specification. So when the stream is deserialized, the values of Name and Age are that of the null and 0, respectively. Fair enough!

But when one writes the class as in the style promoted in PersonReadOnly1, the runtime behaviour is radically different. XmlSerializer throws the following InvalidOperationException, which is caused by the exception in sgen.exe,

System.InvalidOperationException: Unable to generate a temporary class (result=1).
error CS0200: Property or indexer 'TestSerialization.PersonReadOnly1.Name' cannot be assigned to -- it is read only
error CS0200: Property or indexer 'TestSerialization.PersonReadOnly1.Age' cannot be assigned to -- it is read only

   at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
   at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies)
   at System.Xml.Serialization.XmlSerializer.GenerateTempAssembly(XmlMapping xmlMapping, Type type, String defaultNamespace)
   at System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)
   at System.Xml.Serialization.XmlSerializer..ctor(Type type)
   at TestSerialization.TestXmlSerialization.SerializeClassWithNonPublicSetter_PersonReadOnly1() in E:\Projects\SerializationDemo2\TestSerialization\TestXmlSerialization.cs:line 74

The question is: should CLR exhibit the same runtime behaviour regardless of how the class is constructed?

XmlSerializer - Difference in runtime behaviour between MS .Net and Mono runtime

There are several ways to define a class in C# with read-only properties.

You could define it like this:

    [ Serializable ]
    public class PersonReadOnly
    {
        String m_Name;
        Int32 m_Age;
        public String Name {
            get{ return m_Name; }
        }
        public Int32 Age { 
            get{ return m_Age; }
        }

        public PersonReadOnly()
        {
        }

        public PersonReadOnly (String name, Int32 age)
        {
            this.m_Name = name;
            this.m_Age = age;
        }
    }

This is the good old way of doing it. When this class is serialized using Xml Serialization, the values of the properties are not serialized.

Alternately, you can declare one with a private setter or using the auto-generated property syntax with private setter, like this:

    [ Serializable ]
    public class WithAutoPropertyReadOnly
    {
        public String Name { get; private set; }
        public Int32 Age { get; private set; }

        public WithAutoPropertyReadOnly() { }

        public WithAutoPropertyReadOnly( string name, Int32 age )
        {
            this.Name = name;
            this.Age = age;
        }
    }

The end result of this class WithAutoPropertyReadOnly is to produce private setters for properties Name and Age.

While WithAutoPropertiesReadOnly and PersonReadOnly classes are functionally the same, the runtime treatments in CLR (MS .Net) and Mono runtime are very different.

CLR and Mono differences
The Mono runtime used in this experiment is version 2.10.8.1 hosted in Ubuntu 12.04 LTS).

When one tries to construct an XmlSerializer object for the class WithAutoPropertiesReadOnly class, like this:

       XmlSerializer ser = new XmlSerializer( typeof(WithAutoPropertiesReadOnly) ); 

CLR runtime throws an exception of type InvalidOperationException while Mono blissfully serializes and deserializes with XmlSerializer in defiant of the specification.

This is dangerous as it introduces runtime differences that can affect cross-platform compatibility. Irrespective if the above piece of code is run in CLR or Mono, the same runtime behaviour should result.

This anomaly between CLR (runtime 2.0 & 4.0) and Mono only manifested by the presence of non-public property setter. In fact, the exception thrown in CLR is due to the runtime exception thrown by sgen.exe when the runtime tries to generate the temporary serialization DLL.

There is no disagreement when trying to serialize the class PersonReadOnly; both CLR and Mono yield the same result that the values for the properties are not serialized in Xml Serialization.

A bug in Jorte Calendar - Always showing am in the Task popup

This is clearly a bug in Jorte Calendar version 1.5.10 running in Android 4.x.

If you create a Task and assign the start or/and end times as somewhere in the pm, in the brief view, shown here, it always shows am:

Notice the time circled in red.

If one goes ahead and edit this task, the full editing view shows a different story:

The times are clearly defined as in the pm and not in the am. In fact, regardless if one defines the time as am or pm, the brief version dialog box always shows am.

It therefore appears to show that the programmer has failed to parse the times and to choose the am or pm at all! It seems they have left that at the default, which I guess is the am.

While this Calendar app is one of the better ones in the Google Play, its user interface leaves plenty to be desired. For example when defining time, why put the AM/PM selector on the left hand side of the numeral where most others by convention and by standard putting it on the right?

Back to the drawing board and hopefully someone will test it properly and while at it, put the AM/PM selector on the right hand side of the numerals please. Or better still in the locale correct location.

Does anyone know how to get rid of the annoying obstruction in ZDNet in Android?

It seems ZDNet is more interested in annoying its visitors using Android to their web site. Perhaps their web designer does not know how to calculate the right place to put their 'toolbar' showing their comments, votes, Facebook likes etc.

An example using screen capture is probably the best way to illustrate this annoying problem that only seems to exist in ZDNet. I hope the disease does not spread to others.

It does not matter if I am using Firefox or Chrome in my Samsung Tab 10.1, the same annoyance appears when you zoom in on the page.

Here is what the page looks like without zooming in, the normal view:

The 'toolbar' is courteously tugged out of the way on the left hand side. But when you zoom in to the page, the toolbar begins to intrude on the main view - the article - as can be seen by this capture:

The toolbar circled in red begin to become the main focus of the page rather than any article. The bar moves to the right the more you zoom in to the page and becomes bigger, obstructing the more of the article. This is completely inconsiderate.

Can someone tell me what I can do or if there is any add-on to get rid of this kind of visual scum?

Does LibreOffice Team actually test their software for DOCX support?

I don't want to sound like ungrateful as I use and prefer to use LibreOffice even in Windows at those odd moments. I normally reside in Ubuntu and run LO 4.0.1.

As a developer when I see basic operations like this:
1) Create a LO Text file (ODT)
2) Write something and include some embedded graphics (Bitmap) into the document.
3) Then do a "Save as..." to a DOCX file.

failing to produce the correct result when one opens the docx in MS Office 2007, it is clearly a fault in the product or someone did not test their product.

Perhaps the LO team's definition of DOCX is text only file.

I am not sure if the graphic is missing or malformed. Since DOCX file is just a ZIP file, I can unzip the contents and the image file (.png) is awfully small. When one tried to open it, the viewer complaints about the corruption. This seems to indicate to me that their file converter has stuffed up the image in the process.

Surely the above steps must be described in their test procedure and user requirements. Yet the result, as echoed by voluminous chants for help in the Internet, seems to indicate that the LO Team do not include this most basic requirement in their test procedure. Otherwise, how could they not spot that missing graphic. I even doubt if they do test their product.

If LO cannot handle basic DOCX, they should branded that support as experimental or in beta mode and stop trying to make a case that it can handle DOCX file format. Doing so is highly irresponsible.

I am wondering how long will LO come around fixing this sought after bug-fix that has been around for as long as Open-Office/LibreOffice claiming to support DOCX.

Please do not include other fancy stuff and fix this most basic problem first as your product continues to wear a big cross for DOCX support.

Missing cursor keys in Windows 8 Tablet

Cursor keys have also been banished from the soft keyboard of Windows 8 tablet. It may be the first time Microsoft has removed the cursor keys from their soft keyboard.


The soft keyboard part, of the Windows 7 Tablet Input Panel definitely has the cursor keys.

Why is it so inappropriate to have cursor keys in a Touch tablet when it is often impossible to using the finger to move the cursor by one character? Remember because of the font uses, each character is not of the same width and I challenge anyone to move the cursor between two dots with precision.

It is crazy. I am so glad that there is a good practical solution for my Android Tablet.

Cursor keys on tablet - the Android solution

Ever since this new crop of tablets - iPad and Android - came onto the market, I have been stunned to find the absence of these 4 cursor movement keys - Left, Right, Up and Down.

There was a situation when I was asked to compose a document on an iPad in some meeting and it was a severely frustrating experience to type even two lines. Yes I am not the greatest typist on earth but I am not unaccustomed to writing on a computer either.

It is like stuttering in typing; you type something and then you use back spaces to get back to where your correction point and retype. Surely, this is suppose to be a new generation of touch input over the familiar XP Tablet I once used for over 4 years.

If one search Google looking for answers, you come away with an impression of an ideological war to rid cursor keys on tablet. Why? I have yet seen a report from any user-interface laboratory scientifically measuring the benefit of getting rid of the cursor keys. Equally I have yet seen any substantiation of the harm having these keys present.

You have (almost) all the keys in a real QWERTY keyboard and a cursor on the screen and you still need them to type using your soft keyboard. So what harm is having the cursor keys? If one thinks such keys are unnecessary in a touch environment why not getting rid of all keys - no soft keyboard at all.

Microsoft's XP and Win7 Tablet can function efficiently entirely without a soft keyboard. Samsung Note has a pen input that it converts the scribble into text, much like the Transcriber found in the PDA era, and not using soft keyboard.

Android's development team seems to have a habit of forgetting the more important matter and including so called 'cool' stuff.

Thankfully, a group of developers couldn't put up with this nonsense ideological struggle any more and created the Hacker's Keyboard, which you can download from Google Play. It works wonders and its 4 cursor movements keys are like a torch light in a dark tunnel.

Thanks for this sensible invention (or rather reinvention), my frustrating typing sessions in my Toshiba AT1S0 running Android 3.2.1 tablet are in the distance past.

Since I do not have any Apple device and hence I have not paid too much attention looking for its supplement. A casual Google Search for iOS and cursor keys did not yield any glaringly obvious redress but an endless pleads for solutions.