[DataContract]
public class Data
{
    private int[] array;

    public Data()
    {
        this.array = new int[13];
    }

    public int Length { get { return this.array.Length; } }
}

It looks ok, right? Let’s use it then:

DataContractSerializer serializer = new DataContractSerializer(typeof(Data));
Data data = new Data();

using (MemoryStream stream = new MemoryStream())
{
    serializer.WriteObject(stream, data);
    stream.Position = 0; // Rewind

    data = (Data)serializer.ReadObject(stream);

    Console.WriteLine(data.Length); // throws a NullReferenceException
}

Why was this.array not initialized? Well, I gave the answer away in the title; the constructor was never called. It turns out that DataContractSerializer (and BinaryFormatter, by the way), unlike XmlSerializer, creates an uninitialized (without calling any constructors) instance of the type it’s de-serializing. Then data members are de-serialized.

In the example above, a very simple change will fix the issue. If you’re running .Net 3.5 SP1 or later (and you should be), the DataContractSerializer can serialize types without the [DataContract] attribute, i.e. Plain Old CLR Object (POCO) types, as long as the type is public and has a parameter-less constructor (regardless of its visibility) – just like XmlSerializer. And yes, you guessed it, in this case, the constructor will be called.

What if you don’t want to define a parameter-less constructor, or if this isn’t a viable option? You should use one of the serialization callbacks listed in the following article: https://msdn.microsoft.com/en-us/library/ms733734(v=vs.110).aspx

Here’s an example:

[DataContract]
public class Data
{
    private int[] array;

    public Data()
    {
        Initialize();
    }

    private void Initialize()
    {
        this.array = new int[13];
    }

    [OnDeserializing]
    private void SetValuesOnDeserializing(StreamingContext context)
    {
        Initialize();
    }

    public int Length { get { return this.array.Length; } }
}

"SELECT Message FROM Win32_NTLogEvent WHERE EventCode = 7"

And as expected, this will return the entries with event code 7. Now, let’s look at the corresponding C# code, given that you already have a list of event log entries, you explore which property you should use to filter the list using LINQ. Conveniently, you find EventLogEntry.EventID, but it’s obsolete and the compiler warning asks you to use EventLogEntry.InstanceId instead. So, you follow the instructions and do so:

IEnumerable<EventLogEntry> filtered = entries.Where(e => e.InstanceId == 7);

You run the code, and test it; everything works; you don’t think about it twice.

Later on, you inspect certain event log entries, and you find out that your filter didn’t catch them. So, you feel suspicious and debug the code, only to find out that InstanceId returns 3221487623, even though the same entry is showing 7 as its event code in the event viewer.

What’s going on here?

It turns out, the answer was in the remarks section on MSDN:

The EventID property equals the InstanceId with the top two bits masked off. Two event log entries from the same source can have matching EventID values, but have different InstanceId values due to differences in the top two bits of the resource identifier.

Digging deeper, the obsolete EventID property only masks the top two bits, but there’s more we don’t care about in that case, according to MSDN again (see Event Identifiers):

So to really filter by just the event code, the code will look like the following:

IEnumerable<EventLogEntry> filtered = entries.Where(e => (e.InstanceId & 0xFFFF) == 7);

Why didn’t my test catch that?

Because your test wrote the event log entry using the straight-forward WriteEntry method; the remarks section explains:

If the application wrote the event entry using one of the WriteEntry methods, the InstanceId property matches the optional eventId parameter. If the application wrote the event using WriteEvent, the InstanceId property matches the resource identifier specified in the InstanceId of the instance parameter. If the application wrote the event using the Win32 API ReportEvent, the InstanceId property matches the resource identifier specified in the dwEventID parameter.

It's worth noting that using an EventLogQuery doesn't reproduce this issue.

The ? will be replaced by the current database name. To run a query that references a table, you need to make sure that the table exists first, as this query will run on system databases as well.

/// <summary>
/// Represents a message inspector object that can be added to the <c>MessageInspectors</c> collection to view or modify messages.
/// </summary>
public class ClientMessageInspector : IClientMessageInspector
{
    /// <summary>
    /// Enables inspection or modification of a message before a request message is sent to a service.
    /// </summary>
    /// <param name="request">The message to be sent to the service.</param>
    /// <param name="channel">The WCF client object channel.</param>
    /// <returns>
    /// The object that is returned as the <paramref name="correlationState " /> argument of
    /// the <see cref="M:System.ServiceModel.Dispatcher.IClientMessageInspector.AfterReceiveReply(System.ServiceModel.Channels.Message@,System.Object)" /> method.
    /// This is null if no correlation state is used.The best practice is to make this a <see cref="T:System.Guid" /> to ensure that no two
    /// <paramref name="correlationState" /> objects are the same.
    /// </returns>
    public object BeforeSendRequest(ref Message request, IClientChannel channel)
    {
        HttpRequestMessageProperty property = new HttpRequestMessageProperty();

        property.Headers["User-Agent"] = "value";
        request.Properties.Add(HttpRequestMessageProperty.Name, property);

        return null;
    }

    /// <summary>
    /// Enables inspection or modification of a message after a reply message is received but prior to passing it back to the client application.
    /// </summary>
    /// <param name="reply">The message to be transformed into types and handed back to the client application.</param>
    /// <param name="correlationState">Correlation state data.</param>
    public void AfterReceiveReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
    {
        // Nothing special here
    }
}

This interception is a behavior or an extension of WCF endpoints, so one more method needs to be implemented to apply that behavior to the endpoint, the IEndpointBehavior.ApplyClientBehavior method:

/// <summary>
/// Represents a run-time behavior extension for a client endpoint.
/// </summary>
public class CustomEndpointBehavior : IEndpointBehavior
{
    /// <summary>
    /// Implements a modification or extension of the client across an endpoint.
    /// </summary>
    /// <param name="endpoint">The endpoint that is to be customized.</param>
    /// <param name="clientRuntime">The client runtime to be customized.</param>
    public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
    {
        clientRuntime.ClientMessageInspectors.Add(new ClientMessageInspector());
    }
            
    /// <summary>
    /// Implement to pass data at runtime to bindings to support custom behavior.
    /// </summary>
    /// <param name="endpoint">The endpoint to modify.</param>
    /// <param name="bindingParameters">The objects that binding elements require to support the behavior.</param>
    public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
    {
        // Nothing special here
    }

    /// <summary>
    /// Implements a modification or extension of the service across an endpoint.
    /// </summary>
    /// <param name="endpoint">The endpoint that exposes the contract.</param>
    /// <param name="endpointDispatcher">The endpoint dispatcher to be modified or extended.</param>
    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
    {
        // Nothing special here
    }

    /// <summary>
    /// Implement to confirm that the endpoint meets some intended criteria.
    /// </summary>
    /// <param name="endpoint">The endpoint to validate.</param>
    public void Validate(ServiceEndpoint endpoint)
    {
        // Nothing special here
    }
}

The last step is to add the new behavior to the WCF endpoint:

Endpoint.EndpointBehaviors.Add(new CustomEndpointBehavior());

Voilà!

/// <summary>
/// Represents an extension for <see cref="XElement"/>.
/// </summary>
internal static class XElementExtension
{
    /// <summary>
    /// Gets the first (in document order) child element with the specified <paramref name="localName"/>.
    /// </summary>
    /// <param name="parent">The parent element.</param>
    /// <param name="localName">The local name to match.</param>
    /// <returns>An <see cref="XElement"/> that matches the specified <paramref name="localName"/>, or <c>null</c>.</returns>
    public static XElement LocalNameElement(this XElement parent, string localName)
    {
        return parent.Elements().FirstOrDefault(e => e.Name.LocalName == localName);
    }

    /// <summary>
    /// Returns a filtered collection of the child elements of the specified <paramref name="parent"/>, in document order.
    /// Only elements that have a matching <paramref name="localName"/> are included in the collection.
    /// </summary>
    /// <param name="parent">The parent element.</param>
    /// <param name="localName">The local name to match.</param>
    /// <returns>
    /// An <see cref="IEnumerable{T}"/> of <see cref="XElement"/> containing the children that have a matching <paramref name="localName"/>,
    /// in document order.
    /// </returns>
    public static IEnumerable<XElement> LocalNameElements(this XElement parent, string localName)
    {
        return parent.Elements().Where(e => e.Name.LocalName == localName);
    }
}

After you’ve installed it, right click the reference you want to be able to debug in your project, then choose: Enable Debugging. Reflector will get to work and generate the PDBs and source for you:

Note: this doesn’t have to be a .Net Framework assembly. You can enable debugging for any managed referenced assembly. To step into the .Net Framework source, you don’t need Reflector, just enable this from Tools > Options > Debugging:

Happy debugging!

Under the hood, the CreateHeader method returns an instance of an internal class called XmlObjectSerializerHeader, which uses a serializer to write the header:

protected override void OnWriteHeaderContents(XmlDictionaryWriter writer, MessageVersion messageVersion)
{
    Type type;
    lock (this.syncRoot)
    {
        if (this.serializer == null)
        {
            XmlObjectSerializerHeader xmlObjectSerializerHeader = this;
            if (this.objectToSerialize == null)
            {
                type = typeof(object);
            }
            else
            {
                type = this.objectToSerialize.GetType();
            }
            xmlObjectSerializerHeader.serializer = DataContractSerializerDefaults.CreateSerializer(type, this.Name, this.Namespace, 2147483647);
        }
        this.serializer.WriteObjectContent(writer, this.objectToSerialize);
    }
}

If you want full control over the header writing method, and less objects created in the process, consider creating your own message header class. It can be also necessary when you want to format the header’s content in a way that’s not a straight-forward serialized version of its value. For example, if you want to write a header like the following:

<s:Envelope xmlns:s="https://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <CustomHeader xmlns="https://schemas.microsoft.com/42">
      <Id>4a851a6d-c85c-4bd3-9584-c00740332aa4</Id>
    </CustomHeader>
  </s:Header>
  <s:Body />
</s:Envelope>

Using the XmlObjectSerializerHeader will produce the following:

<s:Envelope xmlns:s="https://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <CustomHeader xmlns="https://schemas.microsoft.com/42">
      &lt;id&gt;4a851a6d-c85c-4bd3-9584-c00740332aa4&lt;/id&gt;
    </CustomHeader>
  </s:Header>
  <s:Body />
</s:Envelope>

Because the XmlDictionaryWriter encoded the value’s XML special characters. What you want is to build the custom header yourself:

/// <summary>
/// Represents a custom message header.
/// </summary>
public class CustomMessageHeader : MessageHeader
{
    private const string HeaderName = "CustomHeader";
    private const string HeaderNamespace = "https://schemas.microsoft.com/42";

    /// <summary>
    /// Initializes a new instance of the <see cref="CustomMessageHeader" /> class.
    /// </summary>
    public CustomMessageHeader()
    {
        Id = Guid.NewGuid();
    }

    /// <summary>
    /// Gets the name of the message header.
    /// </summary>
    /// <returns>The name of the message header.</returns>
    public override string Name
    {
        get { return HeaderName; }
    }

    /// <summary>
    /// Gets the namespace of the message header.
    /// </summary>
    /// <returns>The namespace of the message header.</returns>
    public override string Namespace
    {
        get { return HeaderNamespace; }
    }

    /// <summary>
    /// Gets the request ID.
    /// </summary>
    /// <returns>A <see cref="Guid"/> that uniquely identifies a request.</returns>
    public Guid Id { get; private set; }

    /// <summary>
    /// Called when the header content is serialized using the specified XML writer.
    /// </summary>
    /// <param name="writer">
    /// An <see cref="T:System.Xml.XmlDictionaryWriter" /> that is used to serialize the header contents.
    /// </param>
    /// <param name="messageVersion">
    /// The object that contains information related to the version of SOAP associated with a message and its exchange.
    /// </param>
    protected override void OnWriteHeaderContents(XmlDictionaryWriter writer, MessageVersion messageVersion)
    {
        writer.WriteElementString("Id", Id.ToString());
    }
}

Now, to inject that custom message header, messages need to be intercepted before they are sent to the server. This can be done by implementing the IClientMessageInspector.BeforeSendRequest method:

/// <summary>
/// Represents a message inspector object that can be added to the <c>MessageInspectors</c> collection to view or modify messages.
/// </summary>
public class ClientMessageInspector : IClientMessageInspector
{
    /// <summary>
    /// Enables inspection or modification of a message before a request message is sent to a service.
    /// </summary>
    /// <param name="request">The message to be sent to the service.</param>
    /// <param name="channel">The WCF client object channel.</param>
    /// <returns>
    /// The object that is returned as the <paramref name="correlationState " /> argument of
    /// the <see cref="M:System.ServiceModel.Dispatcher.IClientMessageInspector.AfterReceiveReply(System.ServiceModel.Channels.Message@,System.Object)" /> method.
    /// This is null if no correlation state is used.The best practice is to make this a <see cref="T:System.Guid" /> to ensure that no two
    /// <paramref name="correlationState" /> objects are the same.
    /// </returns>
    public object BeforeSendRequest(ref Message request, IClientChannel channel)
    {
        CustomMessageHeader header = new CustomMessageHeader();

        request.Headers.Add(header);

        return header.Id;
    }

    /// <summary>
    /// Enables inspection or modification of a message after a reply message is received but prior to passing it back to the client application.
    /// </summary>
    /// <param name="reply">The message to be transformed into types and handed back to the client application.</param>
    /// <param name="correlationState">Correlation state data.</param>
    public void AfterReceiveReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
    {
        // Nothing special here
    }
}

This interception is a behavior or an extension of WCF endpoints, so one more method needs to be implemented to apply that behavior to the endpoint, the IEndpointBehavior.ApplyClientBehavior method:

/// <summary>
/// Represents a run-time behavior extension for a client endpoint.
/// </summary>
public class CustomEndpointBehavior : IEndpointBehavior
{
    /// <summary>
    /// Implements a modification or extension of the client across an endpoint.
    /// </summary>
    /// <param name="endpoint">The endpoint that is to be customized.</param>
    /// <param name="clientRuntime">The client runtime to be customized.</param>
    public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
    {
        clientRuntime.ClientMessageInspectors.Add(new ClientMessageInspector());
    }
            
    /// <summary>
    /// Implement to pass data at runtime to bindings to support custom behavior.
    /// </summary>
    /// <param name="endpoint">The endpoint to modify.</param>
    /// <param name="bindingParameters">The objects that binding elements require to support the behavior.</param>
    public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
    {
        // Nothing special here
    }

    /// <summary>
    /// Implements a modification or extension of the service across an endpoint.
    /// </summary>
    /// <param name="endpoint">The endpoint that exposes the contract.</param>
    /// <param name="endpointDispatcher">The endpoint dispatcher to be modified or extended.</param>
    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
    {
        // Nothing special here
    }

    /// <summary>
    /// Implement to confirm that the endpoint meets some intended criteria.
    /// </summary>
    /// <param name="endpoint">The endpoint to validate.</param>
    public void Validate(ServiceEndpoint endpoint)
    {
        // Nothing special here
    }
}

The last step is to add the new behavior to the WCF endpoint:

Endpoint.EndpointBehaviors.Add(new CustomEndpointBehavior());

Voilà!

public abstract class Node
{
    private readonly Uri _uri;

    protected Node(string address, string relativePath)
    {
        _uri = new Uri(Path.Combine(address, relativePath));
    }
}

public class Element : Node
{
    private const string relativePath = "/path";

    public Element(string address)
        : base(address, relativePath)
    {
    }
}

Alternatively, it can require that derived types implement a property or a method that returns that value:

public abstract class Node
{
    private readonly Uri _uri;

    protected Node(string address)
    {
        _uri = new Uri(Path.Combine(address, RelativePath));
    }

    protected abstract string RelativePath { get; }
}

public class Element : Node
{
    private const string relativePath = "/path";

    public Element(string address)
        : base(address)
    {
    }

    protected override string RelativePath { get { return relativePath; } }
}

The first approach is more suitable for initializing a new instance; since the relative path value is only used once. However, if the value will be used more frequently, the property solution sounds more like it. For example, extending the MessageHeader class:

public class CustomtMessageHeader : MessageHeader
{
    private const string headerName = "CustomHeader";

    /// <summary>
    /// Gets the name of the message header.
    /// </summary>
    /// <returns>The name of the message header.</returns>
    public override string Name
    {
        get { return headerName; }
    }
}

<ProgressBar IsIndeterminate="True" Foreground="Aquamarine" />

Unfortunately, that doesn’t work. You will need to override the following value in the default theme resource dictionary:

<ResourceDictionary.ThemeDictionaries>
    <ResourceDictionary x:Key="Default">
        <x:String x:Key="ProgressBarIndeterminateForegroundThemeBrush">Aquamarine</x:String>
    </ResourceDictionary>
</ResourceDictionary.ThemeDictionaries>

You can add that override to App.xaml, or to a new resource dictionary that’s merged into App.xaml:

<Application
    x:Class="Sample.App"
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
    
    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="Common/StandardStyles.xaml" />
                <ResourceDictionary Source="Common/CustomStyles.xaml" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>
</Application>

CustomStyles.xaml:

<ResourceDictionary
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
    <!-- Global Overrides -->
    <ResourceDictionary.ThemeDictionaries>
        <ResourceDictionary x:Key="Default">
            <x:String x:Key="ProgressBarIndeterminateForegroundThemeBrush">Aquamarine</x:String>
        </ResourceDictionary>
    </ResourceDictionary.ThemeDictionaries>
</ResourceDictionary>