Hi, thanks for sharing this problem.

This looks to be caused by an IL arrangement in the assembly that the metadata reader isn't able to process. The exception itself looks to be downstream from the true problem ... I think this is going to be hard to track down.

Are you able to narrow this down to the code that triggers the problem? If I can reproduce it, I have a good chance of being able to fix it.

If you're using any IL-manipulation tools in your build system, try turning these off to see if this makes any difference.

Understood. This is usually the case with these sorts of problems :( There are no logs detailed enough to catch this kind of activity because there is so much data involved. If I had a copy of the DLL itself, I might be able to troubleshoot, though usually IP restrictions make this impossible.



To my knowledge, MEF is primarily a run-time concern and doesn't involve static manipulation. DevExpress have been known to introduce their own build steps, so IL manipulation is a possibility. I recommend examining the project XML to see if it imports any .targets files that are outside the standard MS tech stack. Removing these imports temporarily (if they exist) might be an interesting test.



The only thing I can think of here is that v3 introduced IL-level impact detection, which involves extra analysis (hashing) to be performed on the output DLLs. From memory, v3 didn't include any changes that would affect the actual reading of the DLL itself, but the impact detection might be surfacing the issue just because it runs over more of your code. You might want to try setting your impact detection mode (global/solution setting) to 'WatchText' to see if this makes any difference.