CA1707, CA1709, CA1028 on native enums

Question

Hi,

I am using a bunch of P/Invoke calls in my application for system functions such as CreateWindowEx, ... (for WPF HwndHost). Those API calls take a bunch of parameters, such as the window style, which are written as WS_VISIBLE (for example). So in my code I have these enum members, as written in the Microsoft Windows headers.

Unfortunately, FxCop fires CA1707 and CA1709 on these. For other false positives related to native interop, FxCop ignores them if they are in the NativeMethods class, but this isn't working for these false positives.

Also, I have my window styles enum of the base type uint. I took this from pinvoke.net. Is this correct? If it is, then the warning CA1028 also fires in error in this case, since I need this for native interop.

Will this be fixed in the future, or is the only way to ignore these warnings?

Kind regards,
Daniel Rose

Answer 1

If an enum needs to support values outside the Int32 range for p/invoke calls, then you should type it correctly for its intended use (since you essentially have no choice).  However, there's no need to conserve Win32 names on enums, nor is there generally any need to expose such enums publicly.  Other than CA1028, the detected problems are most likely addressable (at the very least by limiting visibility).

Answer 2

I have a WPF class which derives from HwndHost, which I use for creating Win32-windows. I have this as part of a "core" dll. To allow the calling assemblies finer control over the created Win32-window, I have the window-styles which should be set as part of the contructor parameters. So I can't limit visibility.

So the only way to make the warnings go away (besides ignoring them) would be reformatting all the enum values to Pascal-Casing. However (1) this is a bunch of unnecessary work, and (2) those are the Win32 (p-invoke) enums; it is more obvious if I pass WS_VISIBLE | WS_CHILD, for example, versus WsVisible | WsChild.

Answer 3

If you have decided that changing the enum names is not necessary, add suppressions for the rule violations.  That's why they exist.

Answer 4

Yes, I can do that. I was wondering, however, why a P/Invoke method named MY_DLL_METHOD, for example, is ok if it is in the NativeMethods class, but no such construct exists for native enums. After all, we could rename the signature to MyDllMethod and specify via the EntryPoint the correct name.

Answer 5

Sorry, but I cannot reproduce this result.  I do see CA1707 and CA1709 violations for a p/invoke method named in caps with underscores, even if it is placed in a class named NativeMethods.  Is it possible that either your class or method do not have public visibility?