The System.Xaml.XamlObjectWriterException: Failed to create a PointCollection exception seems to happen when trying to load System.Activities.
- the Workflow Designer adds view state information in the xaml at design time (that info contains the PointCollection, as shown in the 2nd image below)
- the view state information can be safely removed from the xaml before instancing the Workflow at runtime (documentation and code sample on how to do this is available on Microsoft WF Docs)
A simple demo workflow, which contains PointCollection in the xaml definition, opened in a Rehosted Workflow Designer:
The view state information (including the PointCollection) in the demo workflow’s xaml definition:
Following @JimCarley ‘s suggestion, sap2010 can also be excluded with a small adjustment to the code from the doc:
static Boolean IsDesignerAttachedProperty(XamlMember xamlMember) { return xamlMember.IsAttachable && (xamlMember.PreferredXamlNamespace.Equals(c_sapNamespaceURI, StringComparison.OrdinalIgnoreCase) || (xamlMember.PreferredXamlNamespace.Equals(c_sap2010NamespaceURI, StringComparison.OrdinalIgnoreCase)); } const String c_sapNamespaceURI = "http://schemas.microsoft.com/netfx/2009/xaml/activities/presentation"; const String c_sap2010NamespaceURI = "http://schemas.microsoft.com/netfx/2010/xaml/activities/presentation";
When executing the view state information removal, make sure that you don’t have loaded in the AppDomain sap or sap2010; if you do the operation from a WPF project (ex: a Rehosted Workflow Designer), you could create a new AppDomain, do the view state removal operation in that context and dispose it afterwards.
Removing the Workflow’s view state information also helps with performance:
- the workflow definition xaml for the runtime is smaller in size
- workflow instance creation is faster
- memory usage is improved
* many thanks to @JimCarley and @DustinMetzgar for their support in reaching to the conclusions above