The problem with namespace attributes and prefixes has been solved, but not yet merged with master.
I'm going to add YAXNodeTypes.Content for serializing dictionary keys or values as element content, also will allow decorating a class with a YAXDictionary or YAXCollection attribute.

However with all the above done the expected serialization result cannot be achieved with the dictionary Value type set as object. Because in this case a polymorphic serialization will occur for sure, and since polymorphic serialization needs meta-data attached, it will be serialized in an XML-element; not XML-attribute, nor XML-content. For now I have changed the Value type to string and will proceed with implementing above items.

Sounds like you've made good progress, which is awesome! Thanks for looking into the issue and figuring out a fix. Changing the Value to string is a good compromise; the values I use are actually strings in the database, so I might be able to figure out another way to work around this.

However, if you take a look at #9, its solution might work as a way to allow YAXNodeTypes.Content serialization of object too, since then you can (hopefully) tell Yax where the realtype attribute should go (plus what it should be named and which values it can have).

If your purpose is parsing an XML created by another application or something, you may find custom serializers handy as well. Take a look at the sample here:
https://github.com/sinairv/YAXLib/blob/master/YAXLibTests/SampleClasses/CustomSerializationTests.cs

Yea, thanks. I'll look into that. :)

Seems like the problem here is due to AttributeSampleBase<T> inheriting List<T>, because Yax' default behavior is not to serialize list properties at all. Removing this inheritance makes the test go green. I need to serialize a couple of list properties as attributes. Is implementing support for this difficult?

YAXLib ignores collection properties by default, to treat them as collection of objects and serialize the members iteratively. However you can add the [YAXNotCollection] attribute to the class, to disable this behavior. The side-effect would be that all the other properties defined in List<> or other collection classes are also serialized, which does not seem favorable.

I'm doing a fix at the moment which looks promising to me.

It's now the serialization of non-collection properties from objects derived from collection classes supported. Please see the following classes and their corresponding tests:

• CollectionWithExtraProperties
• CollectionWithExtraPropertiesAttributedAsNotCollection
• DictionaryWithExtraProperties
• DictionaryWithExtraPropertiesAttributedAsNotCollection