.NET 4.5 Differences

AF Attributes configured with a PI Point Data Reference use a different algorithm in the two different versions to resolve the tag path. The configuration string of a PI Point normally contains a server name, server id, tag name and tag id. The id's are not shown in PI System Explorer but can be seen in an XML export. The id's are not present in all cases, for example, if the tag path was built by substitution parameters from the template, the id's will not be present until a create/update configuration is executed on the attribute or containing element.

Both versions of the PI Point Data Reference will use the server id first to look up the PI Data Archive server and fall back to the name only if the server is not found. The .NET 3.5 PI Point Data Reference will use the tag name first to look up the tag, then, fall back to use the tag id if no tag is found. The .NET 4 PI Point Data Reference will use the tag id first, and only use the name if the tag id is found to be missing on the PI Data Archive. Both versions of the PI Point Data Reference will only use the tag id if the server id matches. The change in the behavior in the .NET 4 version was made to allow the data reference to initialize itself much more quickly as the tag does not need to be resolved prior to its use.

System Digital States from the PI Data Archive are now returned as AFEnumerationValue from the SystemStateSet. For example, when no data was available at the requested time, the .NET 3.5 AF SDK will return a "No Data" Digital State value. The .NET 4 AF SDK will return the NoData system enumeration value. As in previous releases, Non-System Digital States will be converted into the type specified in the associated attribute. However, if the attribute does not have a data specified (shown as <Anything> in PI System Explorer), the type returned will be AFEnumerationValue. In this case, the enumeration value will have a null value for the EnumerationSet property.

Errors returned from the PI Data Archive in the .NET 3.5 AF SDK are returned as an InvalidOperationException. Errors returned from the PI Data Archive in the .NET 4 AF SDK are returned as a PIException or PIConnectionException.

Both the .NET 3.5 and .NET 4 version of the AF SDK will return a PISDK.PIPoint object. However, in the .NET 4 version of the AF SDK, this property will not be cached and will be re-instantiated with each call. Note that the .NET 4 version of the AF SDK does not use the PI SDK and thus retrieving the PISDK.PIPoint object in this manner will require a separate PI SDK connection to the PI Data Archive server. Applications using the .NET 4 version of the AF SDK should use the new PIPoint property which returns a PIPoint defined by the AF SDK.

Both .NET 4 AF SDK and .NET 3.5 AF SDK support buffering via the PI Buffer Subsystem. When writing PI Point events to PI Collectives, buffering is the preferred mechanism to ensure consistent data delivery. If not buffering, the .NET 4 AF SDK will write only to the currently connected member, regardless of whether the connected member is a primary or secondary. If the PI Member Server has the Replication_EnableSDKWriteValues flag set to 0 (the default setting), then writes from the .NET 4 AF SDK will fail unless the application has connected directly to the member via PICollectiveMemberConnect or PICollectiveMemberConnectDirect. The setting of the flag for the currently connected member can be read via the PICollective.AllowWriteValues property. The .NET 3.5 AF SDK utilizes the PI SDK and will automatically fail over to the primary if the Replication_EnableSDKWriteValues flag set to 0 when connected to the PI Data Archive collective.

Writing configuration changes to a PI Collective, such as creating PI Points or setting Point Attributes, is only supported on the primary member. When connected to a collective secondary, the PI SDK's behavior is to automatically fail over to the primary when a configuration change operations is attempted. Writing configuration changes via the .NET 4 AF SDK, AF's behavior is to automatically create a connection to the primary for the operation, but leave the open connection to the secondary in place. This prevents inadvertent fail over for other operations. Like PI SDK, fail over for configuration change operations will not occur in the .NET 4 AF SDK if you have made a specific direct connection to a secondary member.

When an application using the .NET 4 AF SDK is attached to a collective, and the connection is lost to the current member due to network failure, server failure, or server shutdown, the AF SDK will attempt a reconnection to another member. The .NET 4 AF SDK behaves identically to PI SDK in this regard, utilizing the priority setting defined for the collective members to determine the order of connection attempts. If the original connection was made with the AFConnectionPreference of RequirePrimary, then no fail over will occur.

Two additional namespaces are included in the .NET 4 version of the AF SDK: OSIsoft.AF.Data and OSIsoft.AF.PI. These namespaces provide the "Rich Data Access" features of the AF SDK.