We Keep Coding

How to set default values to the properties of dynamically loaded types at runtime for XML serialization

I need to serialize dynamically loaded types' classes using XMLSerializer.
When using XML serializer non initialized values are not being serialized. I dont have control over the assemblies I am working with so can not use XML attributes for specifying default values on properties. So I think I need to set all properties and sub properties to their default values recursively and then serialize. ( Please let me know if there is any better way )
Followed this :
Activator.CreateInstance(propType);
but above line complains about not having a parameterless constructor for some types.
Tried this :
subObject = FormatterServices.GetUninitializedObject(propType);
but this one gives an error "value was invalid" with no inner exception.
Please let me know if you need any further information.

If the types in question don't have public parameterless constructors, you'll struggle. You can get around the attributes issue by using the constructor overload that accepts a XmlAttributeOverrides object, which you can use to fully configure the serializer including the default value (via XmlAttributes.XmlDefaultValue), but some things you can't do - and get around the constructor limitation is one of them.
What is the scenario here?
if you want xml, then I would introduce a DTO layer: some objects that look like the ones you're talking about, but are simple and under your control. Ideal for XmlSerializer. You then write code to map between the two
if you just want serialization (and xml is an implementation detail) then there are other serializers that may help. DataContractSerializer or protobuf-net, for example; either would be more versatile here.

Implementing IXmlSerializable on a generated class that has XmlTypeAttribute

Basically, the initial problem is I need to make a boolean value serialize as 0 or 1. The solution I found was to implement IXmlSerializable, which I did. Unfortunately the class I'm trying to serialize is generated code off a schema and has an XmlTypeAttribute on it. When I try to (de)serialize the object with the XmlSerializer created in the usual manner ( new XmlSerializer(type)) it throws this exception:
System.InvalidOperationException: Only XmlRoot attribute may be specified for the type ______ Please use XmlSchemaProviderAttribute to specify schema type.
Two options come to mind immediatly:
1) remove the attribute in the generated code.
This change would have to be made every time the code was re-generated.
2) Use an XmlAttributeOverrides object when creating the serializer to remove the attribute. This would require the rest of the code base to "know" that it needs to override that attribute. Also, the exception thrown gives absolutly no clue as to what needs to be done to fix it.
Both options kinda stink. Is there a third option?

I have the same problem, for me removing the IXMLSerializable works, I don't use it, and have you tried to hide the true or false with a some logic in the properties? Like this:
private bool mblnFlag;
public String Flag
{
get
{
return mblnFlag;
}
set
{
mblnFlag = (value == "1")
}
}
Of course you should enhance the properties and do more checking, but that's the idea.

How to design to prompt users for new values for properties of deserialized objects?

Right now, I'm currently serializing a class like this:
class Session
{
String setting1;
String setting2;
...etc... (other member variables)
List<SessionAction> actionsPerformed;
}
Where SessionAction is an interface that just has one method. All implementations of the SessionAction interface have various properties describing what that specific SessionAction does.
Currently, I serialize this to a file which can be loaded again using the default .Net binary serializer. Now, I want to serialize this to a template. This template will just be the List of SessionActions serialized to a file, but upon loading it back into memory at another time, I want some properties of these SessionActions to require input from the user (which I plan to dynamically generate GUI controls on the fly depending on the property type). Right now, I'm stuck on determining the best way to do this.
Is there some way I could flag some properties so that upon using reflection, I could determine which properties need input from user? Or what are my other options? Feel free to leave comments if anything isn't clear.

For info, I don't recommend using BinaryFormatter for anything that you are storing long-term; it is very brittle between versions. It is fine for short-lived messages where you know the same version will be used for serialization and deserialization.
I would recommend any of: XmlSerializer, DataContractSerializer (3.0), or for fast binary, protobuf-net; all of these are contract-based, so much more version tolerant.
Re the question; you could use things like Nullable<T> for value-types, and null for strings etc - and ask for input for those that are null? There are other routes involving things like the ShouldSerialize* pattern, but this might upset the serialization APIs.

If you know from start what properties will have that SessionAction, you must implement IDeserializationCallback and put to those props the attribute [NonSerialized]. When you implement the OnDeserialization method you get the new values from the user.

How to tell C# to omit creation of attributes that are default during serialization?

I have a class that is serialized to a XML file. There are several properties that are rarely used but always created. If I delete them within the XML the deserialization still works, because they have the default value.
These unnecessary (bool) attributes make the XML harder to read.
Can I somehow tell C# to omit elements or attributes that still have default value?

Specify the DefaultValueAttribute, and if the value matches, it won't be output.

Rowland has the answer for simple values. For more complex scenarios, you can add a method called public bool ShouldSerializeFoo() (for property Foo) - it it returns false, it won't get serialized.

Use the XMLIgnore() Attribute to mark a property to be ingnored in Serialization / Deserialization.

XML Serialization and empty collections

I have a a property defined as:
[XmlArray("delete", IsNullable = true)]
[XmlArrayItem("contact", typeof(ContactEvent)),
XmlArrayItem("sms", typeof(SmsEvent))]
public List<Event> Delete { get; set; }
If the List<> Delete has no items
<delete />
is emitted. If the List<> Delete is set to null
<delete xsi:nil="true" />
is emitted. Is there a way using attributes to get the delete element not to be emitted if the collection has no items?
Greg - Perfect thanks, I didn't even read the IsNullable documentation just assumed it was signalling it as not required.
Rob Cooper - I was trying to avoid ISerializable, but Gregs suggestion works. I did run into the problem you outlined in (1), I broke a bunch of code by just returning null if the collection was zero length. To get around this I created a EventsBuilder class (the class I am serializing is called Events) that managed all the lifetime/creation of the underlying objects of the Events class that spits our Events classes for serialization.

I've had the same issue where I did not want an element outputted if the field is empty or 0.
The XML outputted could not use xsi:null="true" (by design).
I've read somewhere that if you include a property of type bool with the same name as the field you want to control but appended with 'Specified', the XMLSerializer will check the return value of this property to determine if the corresponding field should be included.
To achieve this without implementing IXMLSerializer:
public List<Event> Delete { get; set; }
[XMLIgnore]
public bool DeleteSpecified
{
get
{
bool isRendered = false;
if (Delete != null)
{
isRendered = (Delete.Count > 0);
}
return isRendered;
}
set
{
}
}

If you set IsNullable=false or just remove it (it is false by default), then the "delete" element will not be emitted. This will work only if the collection equals to null.
My guess is that there is a confusion between "nullability" in terms of .NET, and the one related to nullable elements in XML -- those that are marked by xml:nil attribute. XmlArrayAttribute.IsNullable property controls the latter.

First off, I would say ask yourself "What is Serialization?".
The XmlSerializer is doing exactly what it is supposed to be doing, persisting the current state of the object to XML. Now, I am not sure why the current behaviour is not "right" for you, since if you have initialized the List, then it is initialized.
I think you have three options here:
Add code to the Getter to return null if the collection has 0 items. This may mess up other code you have though.
Implement the IXmlSerializable interface and do all the work yourself.
If this is a common process, then you may want to look at my question "XML Serialization and Inherited Types" - Yes, I know it deals with another issue, but it shows you how to create a generic intermediary serialization class that can then be "bolted on" to allow a serilization process to be encapsulated. You could create a similar class to deal with overriding the default process for null/zero-item collections.
I hope this helps.

You could always implement IXmlSerializer and perform the serialization manually.
See http://www.codeproject.com/KB/cs/IXmlSerializable.aspx for an example.