CA1060: Move P/Invokes to NativeMethods class
For the latest documentation on Visual Studio 2017 RC, see Visual Studio 2017 RC Documentation.
A method uses Platform Invocation Services to access unmanaged code and is not a member of one of the NativeMethods classes.
Platform Invocation methods, such as those that are marked by using the System.Runtime.InteropServices.DllImportAttribute attribute, or methods that are defined by using the
Declare keyword in Visual Basic, access unmanaged code. These methods should be in one of the following classes:
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.
These classes are declared as
Friend, in Visual Basic) and declare a private constructor to prevent new instances from being created. The methods in these classes should be
Friend in Visual Basic).
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.
However, if you are developing libraries for use in other applications, you should consider defining two other classes that are called SafeNativeMethods and UnsafeNativeMethods. These classes resemble the NativeMethods class; however, they are marked by using a special attribute called SuppressUnmanagedCodeSecurityAttribute. When this attribute is applied, the runtime does not perform a full stack walk to make sure that all callers have the UnmanagedCode permission. The runtime ordinarily checks for this permission at startup. Because the check is not performed, it can greatly improve performance for calls to these unmanaged methods, It also enables code that has limited permissions to call these methods.
However, you should use this attribute with great care. It can have serious security implications if it is implemented incorrectly..
For information about how to implement the methods, see the NativeMethods Example, SafeNativeMethods Example, and UnsafeNativeMethods Example.
Do not suppress a warning from this rule.
The following example declares a method that violates this rule. To correct the violation, the RemoveDirectory P/Invoke should be moved to an appropriate class that is designed to hold only P/Invokes.
Imports System NameSpace MSInternalLibrary ' Violates rule: MovePInvokesToNativeMethodsClass. Friend Class UnmanagedApi Friend Declare Function RemoveDirectory Lib "kernel32" ( _ ByVal Name As String) As Boolean End Class End NameSpace
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.
The following example shows an Interaction.Beep method that wraps the MessageBeep function from user32.dll. The MessageBeep P/Invoke is put in the NativeMethods class.
Imports System Imports System.Runtime.InteropServices Imports System.ComponentModel Public NotInheritable Class Interaction Private Sub New() End Sub ' Callers require Unmanaged permission Public Shared Sub Beep() ' No need to demand a permission as callers of Interaction.Beep ' will require UnmanagedCode permission If Not NativeMethods.MessageBeep(-1) Then Throw New Win32Exception() End If End Sub End Class Friend NotInheritable Class NativeMethods Private Sub New() End Sub <DllImport("user32.dll", CharSet:=CharSet.Auto)> _ Friend Shared Function MessageBeep(ByVal uType As Integer) As <MarshalAs(UnmanagedType.Bool)> Boolean End Function End Class
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.
The following example shows an Environment.TickCount property that wraps the GetTickCount function from kernel32.dll.
Imports System Imports System.Runtime.InteropServices Imports System.Security Public NotInheritable Class Environment Private Sub New() End Sub ' Callers do not require Unmanaged permission Public Shared ReadOnly Property TickCount() As Integer Get ' No need to demand a permission in place of ' UnmanagedCode as GetTickCount is considered ' a safe method Return SafeNativeMethods.GetTickCount() End Get End Property End Class <SuppressUnmanagedCodeSecurityAttribute()> _ Friend NotInheritable Class SafeNativeMethods Private Sub New() End Sub <DllImport("kernel32.dll", CharSet:=CharSet.Auto, ExactSpelling:=True)> _ Friend Shared Function GetTickCount() As Integer End Function End Class
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.
The following example shows a Cursor.Hide method that wraps the ShowCursor function from user32.dll.
Imports System Imports System.Runtime.InteropServices Imports System.Security Imports System.Security.Permissions Public NotInheritable Class Cursor Private Sub New() End Sub ' Callers do not require Unmanaged permission, however, ' they do require UIPermission.AllWindows Public Shared Sub Hide() ' Need to demand an appropriate permission ' in place of UnmanagedCode permission as ' ShowCursor is not considered a safe method Dim permission As New UIPermission(UIPermissionWindow.AllWindows) permission.Demand() UnsafeNativeMethods.ShowCursor(False) End Sub End Class <SuppressUnmanagedCodeSecurityAttribute()> _ Friend NotInheritable Class UnsafeNativeMethods Private Sub New() End Sub <DllImport("user32.dll", CharSet:=CharSet.Auto, ExactSpelling:=True)> _ Friend Shared Function ShowCursor(<MarshalAs(UnmanagedType.Bool)> ByVal bShow As Boolean) As Integer End Function End Class