PInvoke calling convention mismatch

By default, the unmanaged C++ compiler generates functions that are _cdecl, but .NET PInvoke requires _stdcall. This causes obvious stack corruption issues and hard-to-find bugs.

Ideally, I would have thought that the .NET runtime could detect that the stack pointer changed after making a PInvoke call, and could have thrown an exception right there. But, since it doesn't, an FxCop rule seems like a good second choice.

It doesn't appear that there is such a rule, I'm hoping that it's possible to either write one myself or better yet have Microsoft supply one.
I already have a not-very-robust rule that simply checks if there is an @ symbol somewhere in the unmanaged function name. Any ideas for a more robust way of checking?

Thanks!

[762 byte] By [NathanB] at [2008-2-23]