Move P/Invokes to NativeMethods class Because it is a P/Invoke method message

Question

Can someone suggest what do I have to do with this message?

CA1060 Move P/Invokes to NativeMethods class Because it is a P/Invoke method, \'UCo

Answer 1

To get rid of the warning, just add your P/Invoke methods to one of the classes below (usually NativeMethods). If you are creating a reusable library, you should put these in either UnsafeNativeMethods or SafeNativeMethods.

---

The msdn page says

To fix a violation of this rule, move the method to the appropriate NativeMethods class. For most applications, moving P/Invokes to a new class that is named NativeMethods is enough.

There are 3 NativeMethods classes they recommend using:

NativeMethods - This class does not suppress stack walks for unmanaged code permission. (System.Security.SuppressUnmanagedCodeSecurityAttribute must not be applied to this class.) This class is for methods that can be used anywhere because a stack walk will be performed.

SafeNativeMethods - This class suppresses stack walks for unmanaged code permission. (System.Security.SuppressUnmanagedCodeSecurityAttribute is applied to this class.) This class is for methods that are safe for anyone to call. Callers of these methods are not required to perform a full security review to make sure that the usage is secure because the methods are harmless for any caller.

UnsafeNativeMethods - This class suppresses stack walks for unmanaged code permission. (System.Security.SuppressUnmanagedCodeSecurityAttribute is applied to this class.) This class is for methods that are potentially dangerous. Any caller of these methods must perform a full security review to make sure that the usage is secure because no stack walk will be performed.

But most of the time it is okay to just use the NativeMethods class (this will at least get rid of the warning you are seeing):

internal static class NativeMethods    
{        
    [DllImport("kernel32.dll")]
    internal static extern bool RemoveDirectory(string name);   
}

There is some discussion about this here, and the article linked above gives some suggestions on when to use each of the 3 classes:

NativeMethods

Because the NativeMethods class should not be marked by using SuppressUnmanagedCodeSecurityAttribute, P/Invokes that are put in it will require UnmanagedCode permission. Because most applications run from the local computer and run together with full trust, this is usually not a problem. However, if you are developing reusable libraries, you should consider defining a SafeNativeMethods or UnsafeNativeMethods class.

SafeNativeMethods

P/Invoke methods that can be safely exposed to any application and that do not have any side effects should be put in a class that is named SafeNativeMethods. You do not have to demand permissions and you do not have to pay much attention to where they are called from.

UnsafeNativeMethods

P/Invoke methods that cannot be safely called and that could cause side effects should be put in a class that is named UnsafeNativeMethods. These methods should be rigorously checked to make sure that they are not exposed to the user unintentionally. The rule CA2118: Review SuppressUnmanagedCodeSecurityAttribute usage can help with this. Alternatively, the methods should have another permission that is demanded instead of UnmanagedCode when they use them.

Answer 2

Oh!

I found an answer

https://msdn.microsoft.com/library/ms182161.aspx

using System;
using System.Runtime.InteropServices;

    namespace DesignLibrary
    {
    // Violates rule: MovePInvokesToNativeMethodsClass.
        internal class UnmanagedApi
        {
            [DllImport("kernel32.dll")]
            internal static extern bool RemoveDirectory(string name);
        }
    }