Introduction

DataContractSerializer only serializes the members you explicitly include when a type is decorated with DataContract. That means ignoring a property is usually simple: do not mark it with DataMember. The real complexity comes from knowing when implicit serialization is active, how inheritance behaves, and how to exclude data safely without breaking contracts.

The Core Rule: Only DataMember Values Are Serialized

When a type is marked with DataContract, only members marked with DataMember participate in serialization.

1using System;
2using System.IO;
3using System.Runtime.Serialization;
4using System.Text;
5using System.Xml;
6
7[DataContract]
8public class UserProfile
9{
10    [DataMember]
11    public string UserName { get; set; }
12
13    [DataMember]
14    public string Email { get; set; }
15
16    public string InternalToken { get; set; }
17}
18
19static string Serialize<T>(T value)
20{
21    var serializer = new DataContractSerializer(typeof(T));
22    using var stream = new MemoryStream();
23    using var writer = XmlWriter.Create(stream);
24    serializer.WriteObject(writer, value);
25    writer.Flush();
26    return Encoding.UTF8.GetString(stream.ToArray());
27}
28
29var profile = new UserProfile
30{
31    UserName = "ada",
32    Email = "[email protected]",
33    InternalToken = "secret"
34};
35
36Console.WriteLine(Serialize(profile));

InternalToken is ignored because it is not marked with DataMember.

Do Not Mix Up IgnoreDataMember

If the type is being serialized using opt-out style elsewhere, IgnoreDataMember can explicitly exclude a member. With DataContractSerializer, the more common pattern is opt-in through DataContract plus DataMember.

Explicit exclusion example:

1using System.Runtime.Serialization;
2
3[DataContract]
4public class OrderDto
5{
6    [DataMember]
7    public int Id { get; set; }
8
9    [DataMember]
10    public decimal Total { get; set; }
11
12    [IgnoreDataMember]
13    public string DebugNotes { get; set; }
14}

IgnoreDataMember is useful when you want the exclusion to be obvious in code review.

Use Separate DTOs for Stronger Contracts

If a property should never leave your boundary, the best design is often not serializer configuration at all. Instead, create a DTO that only contains the fields you want to expose.

1[DataContract]
2public class UserEntity
3{
4    [DataMember]
5    public string UserName { get; set; }
6
7    [DataMember]
8    public string Email { get; set; }
9
10    [DataMember]
11    public string PasswordHash { get; set; }
12}
13
14[DataContract]
15public class UserPublicDto
16{
17    [DataMember]
18    public string UserName { get; set; }
19
20    [DataMember]
21    public string Email { get; set; }
22}

This is more explicit and safer than relying on one serializer configuration to protect sensitive fields.

Control Optional Members Carefully

Sometimes you want a property available in the model but not always present in output. EmitDefaultValue = false is not the same as ignoring a property. It only suppresses serialization when the member has its default value.

1[DataContract]
2public class AuditInfo
3{
4    [DataMember]
5    public string Name { get; set; }
6
7    [DataMember(EmitDefaultValue = false)]
8    public string Comment { get; set; }
9}

If Comment is null, it may be omitted. If it has a value, it is still serialized. That is very different from permanent exclusion.

Verify Output With Tests

Serialization behavior should be tested, especially when omitting sensitive data.

1using Xunit;
2
3public class SerializationTests
4{
5    [Fact]
6    public void InternalToken_IsNotSerialized()
7    {
8        var xml = Serialize(new UserProfile
9        {
10            UserName = "ada",
11            Email = "[email protected]",
12            InternalToken = "secret"
13        });
14
15        Assert.DoesNotContain("InternalToken", xml);
16        Assert.DoesNotContain("secret", xml);
17    }
18}

This catches accidental DataMember additions during refactors.

Inheritance and Versioning Considerations

If base classes and derived classes use data contracts, be explicit about which members belong to the serialized contract. Also remember that removing a serialized member can break consumers that expect it. Excluding a property is easy technically, but contract changes still need versioning discipline.

When compatibility matters, prefer additive changes and separate output DTOs over silent serializer rule changes.

Common Pitfalls

One common mistake is assuming all public properties are serialized even when DataContract is present. Another is using EmitDefaultValue = false and thinking that means a property is fully ignored. Developers also expose domain entities directly and hope serializer attributes will handle security. Inheritance can make contract membership less obvious if attributes are scattered. Finally, teams often skip serialized-output tests and miss accidental leakage of internal fields.

Summary

• With DataContractSerializer, the normal way to ignore a property is to omit DataMember.
• Use IgnoreDataMember when you want the exclusion to be explicit.
• Do not confuse omission with EmitDefaultValue = false.
• Prefer dedicated DTOs when excluded data is sensitive or boundary-specific.
• Add serialization tests to verify that ignored fields never appear in output.
• Treat serializer configuration as part of your public contract, not just an internal detail.