Xml Serialization Bug + Control.Invoke Bug (Or: My Adventures In .NET!) [modified]
-
Found two bugs in .NET today. Well, the second is not as much of a bug since it's SORTA documented, but it's confusing none-the-less. Bug #1: System.Xml.Serialization.XmlSerializer ingoring included types. Background: System.Xml.Serialization is used to convert a class instance into an XML file on disk, or vise versa. It is useful for easily saving a "user options" class to disk and then reloading it next time the program is run. Of course it's tricky to represent different types of data as pure text in XML, so there are constraints to presumably keep it from trying to serialize classes that don't support it. If your class that you want to serialize has a property or field of some other class, that other class is considered "allowed". However classes which INHERIT from the other class are not. If you attempt to serialize when your instance contains class instances not explicitly mentioned in the class declaration, you get an exception. This was happening to me. There are a couple solutions to this, both of which involve letting the serializer know that a specific type is OK to serialize by explicitly declaring it. Problem: None of the solutions were working for me, none had any effect at all. However, I was using several levels of classes that I was serializing all at once, and the inherited-type was a couple levels deep. The serializer seems to recurse as it travels down levels, and I can only assume that it fails to pass along the "allowed types" parameter or any of the discovered "XmlInclude" Attributes! Workaround: Fortunately, taking direct control of the serialization process as described here works like a charm, although the output XML has a few too many tags for my liking I am just happy that it works. Bug #2: If you call Control.Invoke while certain stuff is happening to a control and do certain other stuff, cross thread exception! Problem: Not sure, it's not one thing. Probably caused by helper threads invoking code while I'm still in my form constructor. Workaround: Fire off helper threads as late as possible when spawned from the constructor. Also I had to check for ListView.Created == true when calling ListView.AutoResizeColumns or else I'd get an exception from Application.Run. Might be a separate problem though.
modified on Monday, September 28, 2009 10:11 PM
-
Found two bugs in .NET today. Well, the second is not as much of a bug since it's SORTA documented, but it's confusing none-the-less. Bug #1: System.Xml.Serialization.XmlSerializer ingoring included types. Background: System.Xml.Serialization is used to convert a class instance into an XML file on disk, or vise versa. It is useful for easily saving a "user options" class to disk and then reloading it next time the program is run. Of course it's tricky to represent different types of data as pure text in XML, so there are constraints to presumably keep it from trying to serialize classes that don't support it. If your class that you want to serialize has a property or field of some other class, that other class is considered "allowed". However classes which INHERIT from the other class are not. If you attempt to serialize when your instance contains class instances not explicitly mentioned in the class declaration, you get an exception. This was happening to me. There are a couple solutions to this, both of which involve letting the serializer know that a specific type is OK to serialize by explicitly declaring it. Problem: None of the solutions were working for me, none had any effect at all. However, I was using several levels of classes that I was serializing all at once, and the inherited-type was a couple levels deep. The serializer seems to recurse as it travels down levels, and I can only assume that it fails to pass along the "allowed types" parameter or any of the discovered "XmlInclude" Attributes! Workaround: Fortunately, taking direct control of the serialization process as described here works like a charm, although the output XML has a few too many tags for my liking I am just happy that it works. Bug #2: If you call Control.Invoke while certain stuff is happening to a control and do certain other stuff, cross thread exception! Problem: Not sure, it's not one thing. Probably caused by helper threads invoking code while I'm still in my form constructor. Workaround: Fire off helper threads as late as possible when spawned from the constructor. Also I had to check for ListView.Created == true when calling ListView.AutoResizeColumns or else I'd get an exception from Application.Run. Might be a separate problem though.
modified on Monday, September 28, 2009 10:11 PM
The_Mega_ZZTer wrote:
Workaround: Fortunately, taking direct control of the serialization process as described here works like a charm, although the output XML has a few too many tags for my liking I am just happy that it works.
Hi, The_Mega_ZZTer, I am curious if there is a "missing link" that was supposed to be included here with this statement. I've read your description of bug #1 carefully, and can't seem to infer what the "workaround" would be other than to not call serialization on nested inherited types. thanks for clarifying, best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844