Using Serialized .NET Objects for AFPlugin Configuration: A Time-Saving Technique

Streamlining AFPlugin Configuration Management with Serialized CLR Objects

As PI System engineers and AF Plugin developers, we often face the challenge of managing complex configuration data for custom Data References and Extensions. Traditionally, the AF SDK provides a ConfigString property—a single string field meant to hold all configuration information for your plugin. This approach forces plugin authors to perform tedious string parsing, packing and unpacking multiple property values into delimited key-value pairs. While functional, this method is neither robust nor developer-friendly.

A Smarter Approach: Storing Serialized Configuration Objects

Recently, a developer shared a helpful pattern: leverage .NET serialization to represent your plugin configuration as a CLR object, then serialize it into the ConfigString property. Instead of handcrafting every get/set and parsing string segments, you define a simple configuration class, serialize it (using XML, JSON, or another format), and store the result. When needed, simply deserialize it back to your object type.

Benefits

• Simplicity: Define your configuration structure as a typed object, and let serializers handle the details.
• Maintainability: Refactoring or adding configuration options becomes a matter of editing your class definition, not regex spaghetti.
• UI Integration: Configuration forms can bind directly to property values on your configuration object, reducing code duplication.

Sample Implementation Using DataContractSerializer

// Backing field for ConfigString
private string ConfigString_backing;
public override string ConfigString
{
    get { return ConfigString_backing; }
    set { ConfigString_backing = value; SaveConfigChanges(); }
}

public MyPluginConfiguration GetConfiguration()
{
    var serializer = new DataContractSerializer(typeof(MyPluginConfiguration));
    using (var stream = new MemoryStream(Encoding.UTF8.GetBytes(ConfigString)))
    {
        return serializer.ReadObject(stream) as MyPluginConfiguration;
    }
}

public void SetConfiguration(MyPluginConfiguration config)
{
    var serializer = new DataContractSerializer(typeof(MyPluginConfiguration));
    using (var stream = new MemoryStream())
    {
        serializer.WriteObject(stream, config);
        stream.Seek(0, SeekOrigin.Begin);
        using (var reader = new StreamReader(stream))
        {
            ConfigString = reader.ReadToEnd();
        }
    }
}

Tip: Consider using DataContractJsonSerializer if you want compact, human-readable configuration strings. JSON is typically more space-efficient than XML.

About ConfigString Length Limits

• AF 2.3 and below: Max 3500 Unicode characters for ConfigString.
• AF 2.4+: Limit greatly increased; with server & client update, effective restriction removed (database LOB field max is ~2GB).

Note: If you plan to support older systems or extremely large config objects, ensure you handle string length gracefully.

Could This Be Built into AFPlugin?

Many developers agree: a built-in, object-oriented config management helper in the AFPlugin base class would save time and headaches. Until such a feature is standard, this serialization approach is a proven, effective alternative.

Conclusion

Serializing your configuration objects can significantly improve the developer experience when creating AF Plugins. It elevates configuration from mere string-packing to clear, maintainable code. With modern AF versions removing most size restraints, this technique is both practical and scalable for complex configuration needs.

Have you used serialization for AFPlugin configuration before? What best practices or challenges have you encountered? Share your experiences in the comments!