locked
Rehosted Workflow Designer breaking when updating to .net 4.5 RRS feed

  • Question

  • I am rehosting the workflow designer.  It works PERFECTLY!

    ....then I installed .NET 4.5 on my system. 

    In order to get the Workflow's XAML from the workflow designer, I first call workflowDesigner.Flush() and then get the XAML by checking its Text property.  Once I installed 4.5 on my machine, I get an error on Flush with the following stack trace:

    System.Reflection.TargetException: Object does not match target type.
       at System.Reflection.RuntimeMethodInfo.CheckConsistency(Object target)
       at System.Reflection.RuntimeMethodInfo.InvokeArgumentsCheck(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
       at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
       at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, Object[] index)
       at Microsoft.Activities.Presentation.Xaml.XamlObjectReaderWithSequence.GetRealObject()
       at Microsoft.Activities.Presentation.Xaml.XamlObjectReaderWithSequence.Read()
       at Microsoft.Activities.Presentation.Xaml.ViewStateXamlHelper.RemoveIdRefs(XamlObjectReader inputReader)
       at Microsoft.Activities.Presentation.Xaml.WorkflowDesignerXamlHelper.CreateXamlObjectReaders(Object deserializedObject, XamlSchemaContext schemaContext, XamlReader& newWorkflowReader, XamlObjectReaderWithSequence& deserializedObjectSequenceBuilder)
       at Microsoft.Activities.Presentation.Xaml.WorkflowDesignerXamlHelper.<>c__DisplayClass4.<SerializeToString>b__2(XamlWriter writer)
       at Microsoft.Activities.Presentation.Xaml.WorkflowDesignerXamlHelper.UsingXamlWriter[T](T xamlWriter, Action`1 work)
       at Microsoft.Activities.Presentation.Xaml.WorkflowDesignerXamlHelper.UsingXamlWriter[T](T xamlWriter, Action`1 work)
       at Microsoft.Activities.Presentation.Xaml.WorkflowDesignerXamlHelper.UsingXamlWriter[T](T xamlWriter, Action`1 work)
       at Microsoft.Activities.Presentation.Xaml.WorkflowDesignerXamlHelper.SerializeToString(Object obj, String fileName)
       at System.Activities.Presentation.WorkflowDesigner.WriteModelToText(String fileName)

    ...NOTE:  I can not find a class anywhere called XamlObjectReaderWithSequence.  I tried googling, Reflector and the Object Browser and can not track down this class.

    I went back to my source and set the Project's Target Framework to 4.5 and the error still happens when I try to call Fluch on the workflow designer.

    I tried, targeting the workflow designer's configuration so that it would use 4.0 XAML as per the following article: http://nooneytech.blogspot.com/2012/08/usage-and-deployment-of-workflow.html#!/2012/08/usage-and-deployment-of-workflow.html

    That didn't work either.

    Its worth mentioning that when I call Flush on the designer, the exception does not get caught on the executing thread.  I actually just get back the original, unmodofied XAML when I check the text property of the designer.  The exception is only visible because it is displayed within the design surface itself.

    Any Ideas?  This one really has me stumped

    Wednesday, September 26, 2012 1:39 PM

Answers

  • I've found a number of things...

    First, when I was looking at things in reflector, I was looking at the wrong assembly. I just opened Reflector and since that assembly was already loaded, I assumed that was the correct one since .net 4.5 is supposed to overwrite 4.0.  The class does not exist in the .net 4.0 version of System.Activities.Presentation.dll

    I did take your suggection, though and started looking at individual activities to see if there was a particular one that was causing the issue.  Thanks to you, I figured it out!

    a couple of our activities have properties that are of type int[]

    Previously, the designer was able to serialize these without a problem:

    int[] {2,4,6,8} <=> "{2, 4, 6, 8}"

    However, the new serialization process obviously does not have this baked into it. I'm not sure if I have to create a typeconverter and stick it onto the property definition or change the property type to string and internally perform all of my conversions.  However, I can be assured that upgrading our servers will require a redeployment of our code.

    I do appreciate the help, man

    Thursday, September 27, 2012 1:29 PM

All replies

  • It's there in reflector. At least it is for me.

    Name: Microsoft.Activities.Presentation.Xaml.XamlObjectReaderWithSequence
    Assembly: System.Activities.Presentation, Version=4.0.0.0

    I have no idea yet what the cause is, but it seems like it is probably related to saving the designer content or especially view state somehow.

    Does the issue happen regardless of what activities you have in your workflow?
    Tim

    • Marked as answer by houtexwebdev Thursday, September 27, 2012 1:29 PM
    • Unmarked as answer by Tim Lovell-Smith Wednesday, October 3, 2012 5:49 PM
    Wednesday, September 26, 2012 9:04 PM
  • I've found a number of things...

    First, when I was looking at things in reflector, I was looking at the wrong assembly. I just opened Reflector and since that assembly was already loaded, I assumed that was the correct one since .net 4.5 is supposed to overwrite 4.0.  The class does not exist in the .net 4.0 version of System.Activities.Presentation.dll

    I did take your suggection, though and started looking at individual activities to see if there was a particular one that was causing the issue.  Thanks to you, I figured it out!

    a couple of our activities have properties that are of type int[]

    Previously, the designer was able to serialize these without a problem:

    int[] {2,4,6,8} <=> "{2, 4, 6, 8}"

    However, the new serialization process obviously does not have this baked into it. I'm not sure if I have to create a typeconverter and stick it onto the property definition or change the property type to string and internally perform all of my conversions.  However, I can be assured that upgrading our servers will require a redeployment of our code.

    I do appreciate the help, man

    Thursday, September 27, 2012 1:29 PM
  • Hello,

    we are now in this situation, some of our customers are installing .NET 4.5 and are now getting this problem with some of our custom activities that have properties defined as string[]. Strangely, workflow xaml definition is correctly read by the designer, the error is only hit when modifying the definition and trying to serialize back to xaml.

    Is there any solution that doesn't involve changing the type of these properties?

    Thank you

    Thursday, May 9, 2013 6:17 AM
  • Here's what we ended up doing.

    In our case, we had properties that were integer arrays. We made a compromise in that we changed the properties to strings types.  However, the strings are actually json serialized instances of integer arrays.  Here's the process we went through:

    1) Change the property to type String

    2) In the activity designer, we had code that would add items to the array type properties on the activity.  We changed the designer so that it (1) creates the array by de-serializing the property value (2) implement the same logic, but we changed the de-serialized array instead of the actual property (3) serialize the array back to the string property.

    3) In the Activity's implementation, take the code that used that propertyand change it so that it first de-serialized the string value, and then allow the code to function as normal

    Then we created a couple of workflows using this activity with the new property so that we could be totally aware of what the XAML looked like

    4)  This was the tricky part, we has to create a script (we used powershell, but you could just as easily create a console app) that opened all of the existing workflow documents and modified the xaml so that it would work with the activity's new implementation.

    Then we did some regression testing to make sure that everything worked correctly with .NET 4.0 then we upgraded and it was all unicorns and rainbows.

    Since we're not changing the workflow's execution structure, persisted instances of the workflow that were created before the change still work after the change was made. This is in spite of the fact that you can't change a workflow definition for persisted instances.  We're looking at a special case where although the XAML is being changed, it is structurally identical.

    I know it sounds like a huge work-around....but it worked

    Friday, May 10, 2013 12:44 AM
  • Thanks a lot for your thorough aswer!

    Anyway I think I found a simpler solution for our problem, we're still evaluating if it covers all of our cases but it boils down to:

    - Create a TypeConverter for our string[] properties that return a System.Windows.Markup.ArrayExtension:

        public class StringArrayConverter : ArrayConverter
        {
            public override object ConvertTo(ITypeDescriptorContext context, System.Globalization.CultureInfo culture, object value, Type destinationType)
            {
                if (destinationType == typeof(MarkupExtension))
                    return new ArrayExtension((string[])value);
                return null;
            }
    
            public override bool CanConvertTo(ITypeDescriptorContext context, Type destinationType)
            {
                if (destinationType == typeof(MarkupExtension))
                    return true;
                return false;
            }
        }

    - On our activity code, decorate our string[] properties with the StringArrayConverter attribute:

            [TypeConverter(typeof(StringArrayConverter))]
            public string[] RoleCodes { get; set; }

    This way we don't need to change our WF definitions, and everything seems to work as expected.

    Regards

    Friday, May 10, 2013 6:37 AM
  • I'm not saying it won't work, but for some reason I remember trying to go with that option and we came across a case where it did not work.  I can't remember exactly what that case was, however (it was 8 months ago, after all).

    Let me know how it works out.  If it works, I'd appreciate you letting me know.

    Monday, May 13, 2013 3:12 PM