I have been battling with the following error and finally decided to delve into the debugger and isolate the gremlin. It just got worse, because when I finally found the method …LoadProvider(), which loads each Adapter DLL in the PlugIns directory and looks for the IProvider interface. The reflection code claimed that the IProvider interface was not a known type within any of the adapters and therefore returned an empty provider dictionary to the pipeline … which in turn threw its toys out of the cot.
This is the problematic logic … statement on line 29 claims that type == null. Looking at the assembly in Reflector claims otherwise … which is when I called my colleague Terry for help.
Rule 42 (the answer to IT) … when you are unable to resolve a problem within a reasonable period of time, call a colleague and discuss the problem on the whiteboard. I do not know why I always tell everyone to adhere to this rule, yet I constantly find myself breaking it and exploring black holes 🙁
If any of your TFS Integration Platform adapters have the copy to local property set to true as part of their project build properties, the EditorFoundation, EntityModel and Toolkit assemblies are copied to the PlugIns directory as well. Once these assemblies make themselves at home the the PlugIns directory, the reflection logic misbehaves and fails to locate the IProvider interface type.
This is a known bug and is under investigation. In the interim, please ensure that only Assemblies with an IProvider interface are located within the PlugIns directory. Remove all other assemblies … or face the gremlins as above.
I will update this post as soon as we have a resolution for the bug.