The past few weeks I have been working with a team on a fairly large WF implementation that will run a few thousands of wokflows a Day(around 300.000 a day!). You can imagine that this has quite some fun Non functional requirements and currently we are doing a proof of concept to see if we can meet performance requirements. (I must say that I am pretty confident we can make this work)

During the development of custom activities we ran into a very irritating issue that we finally figured out to work around. The problem is that when we develop a custom activity and give it a dependency property of e.g. the type string and then we use it in a workflow things can just bind so that is good. The problem occurs when a developer changes the type of the dependency property to e.g. MyCustomType and then after compilation tries to bind the property of the activity to a new property on the workflow of the correct type.

The designer will now generate a following error:

Path resolved to Referenced activity Property 'MyProperty' whose PropertyType 'MyNamespace.MyCustomType ' does not match with the Target Type 'MyNamespace. MyCustomType'.

Now isn’t that sweet…. It tells me that the type that is exactly the same does not match the type I just try to bind.

It appears that this is caused by some kind of caching that occurs in the visual studio IDE. Once you used the activity with the previous datatype and you change the type later on, it will not pick up the correct new type. The only remedy at this moment is that you need to close the VS IDE and start it up again. Now the IDE will pick up the new types of the property and you can bind your property.

Hope this prevents you from becoming bold while pulling your hairs when you think you hit rock bottom with this exception J 

CTO at Xpirit, Microsoft Regional Director, Visual studio ALM MVP, Speaker, Pluralsight Author and IT Architect Consultant