While updating my MSMQ Activities for Windows Workflow Foundation, I ran into a strange issue with the WF designer when working with XOML-based workflows. The problem I was trying to solve was something like the following: The MsmqReceiveActivity had an attached dependency property called Label, as well as a regular .NET property around it. In code based workflows, that worked just fine. However, when designing XOML based workflows, it appeared to worked fine as well, but as soon as you closed the designer and tried opening the workflow again you'd get an error saying that the activity class needed to implement static GetLabel() and SetLabel() accessors. This was funky because the activity actually had those! Looking at the generated XOML code, it was doing something like this: < ns0:MsmqReceiveActivity x:Name = " ReceiveMessage " Queue = " {ActivityBind SampleWorkflow2,Path=QUEUE} " ns0:MsmqReceiveActivity.Label = " {ActivityBind SampleWorkflow2,Path=_labelReceived} " MessageType = " {x:Type TestApp.Customer} " Label = " {x:Null} " > < ns0:MsmqReceiveActivity.MessageReceived > < ActivityBind Name = " SampleWorkflow2 " Path = " _customerReceived " /> </ ns0:MsmqReceiveActivity.MessageReceived > </ ns0:MsmqReceiveActivity > Looking closely I finally discovered the issue: The problem was that the Label property was getting serialized twice! One was the attached dependency property itself (with the ActivityBind), the other was the normal .NET property! Knowing that, it was easy to fix, by just telling the designer not to serialize the regular .NET property: > [ SRDescription ( "Recv_Label" )] [ Category ( "Activity" )] [ ValidationOption ( ValidationOption .Optional)] [ DesignerSerializationVisibility ( DesignerSerializationVisibility .Hidden)] public string Label { get { return ( string ) base .GetValue(LabelProperty); } set { base .SetValue(LabelProperty, value ); } } Testing all of this is when I realized that everytime my activity serialized incorrectly in the XOML designer, and I caused the designer error when opening again, the designer would get "stuck" with the invalid XOML apparently getting it cached somewhere. Even if I manually went into the .xoml file and deleted the entire invalid block of code (completely removing the MsmqReceiveActivity instance), as soon as I opened the file again it would use the original, invalid XOML code. I actually had to close and restart Visual Studio to be able to fix the code. So, if this happens to you, restarting Visual Studio seems to do the trick. That said, I do wonder whether this "caching" going on was intentional or if it's a problem with the designer... > Read More...