You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A method calls an overload of the <xref:System.Windows.Forms.MessageBox.Show%2A?displayProperty=fullName> method that does not take a <xref:System.Windows.Forms.MessageBoxOptions?displayProperty=fullName> argument.
30
33
31
-
## Rule Description
32
-
To display a message box correctly for cultures that use a right-to-left reading order, the <xref:System.Windows.Forms.MessageBoxOptions> and <xref:System.Windows.Forms.MessageBoxOptions> members of the <xref:System.Windows.Forms.MessageBoxOptions> enumeration must be passed to the <xref:System.Windows.Forms.MessageBox.Show%2A> method. Examine the <xref:System.Windows.Forms.Control.RightToLeft%2A?displayProperty=fullName> property of the containing control to determine whether to use a right-to-left reading order.
34
+
A method calls an overload of the <xref:System.Windows.Forms.MessageBox.Show%2A?displayProperty=fullName> method that does not take a <xref:System.Windows.Forms.MessageBoxOptions?displayProperty=fullName> argument.
35
+
36
+
## Rule description
37
+
38
+
To display a message box correctly for cultures that use a right-to-left reading order, pass the [MessageBoxOptions.RightAlign](<xref:System.Windows.Forms.MessageBoxOptions.RightAlign>) and [MessageBoxOptions.RtlReading](<xref:System.Windows.Forms.MessageBoxOptions.RtlReading>) fields to the <xref:System.Windows.Forms.MessageBox.Show%2A> method. Examine the <xref:System.Windows.Forms.Control.RightToLeft%2A?displayProperty=fullName> property of the containing control to determine whether to use a right-to-left reading order.
39
+
40
+
## How to fix violations
33
41
34
-
## How to Fix Violations
35
-
To fix a violation of this rule, call an overload of the <xref:System.Windows.Forms.MessageBox.Show%2A> method that takes a <xref:System.Windows.Forms.MessageBoxOptions> argument.
42
+
To fix a violation of this rule, call an overload of the <xref:System.Windows.Forms.MessageBox.Show%2A> method that takes a <xref:System.Windows.Forms.MessageBoxOptions> argument.
36
43
37
-
## When to Suppress Warnings
38
-
It is safe to suppress a warning from this rule when the code library will not be localized for a culture that uses a right-to-left reading order.
44
+
## When to suppress warnings
45
+
46
+
It is safe to suppress a warning from this rule when the code library will not be localized for a culture that uses a right-to-left reading order.
39
47
40
48
## Example
41
-
The following example shows a method that displays a message box that has options that are appropriate for the reading order of the culture. A resource file, which is not shown, is required to build the example. Follow the comments in the example to build the example without a resource file and to test the right-to-left feature.
The following example shows a method that displays a message box that has options that are appropriate for the reading order of the culture. A resource file, which is not shown, is required to build the example. Follow the comments in the example to build the example without a resource file and to test the right-to-left feature.
# CA1403: Auto layout types should not be COM visible
24
+
21
25
|||
22
26
|-|-|
23
27
|TypeName|AutoLayoutTypesShouldNotBeComVisible|
@@ -26,28 +30,35 @@ ms.workload:
26
30
|Breaking Change|Breaking|
27
31
28
32
## Cause
29
-
A Component Object Model (COM) visible value type is marked with the <xref:System.Runtime.InteropServices.StructLayoutAttribute?displayProperty=fullName> attribute set to <xref:System.Runtime.InteropServices.LayoutKind?displayProperty=fullName>.
30
33
31
-
## Rule Description
32
-
<xref:System.Runtime.InteropServices.LayoutKind> layout types are managed by the common language runtime. The layout of these types can change between versions of the .NET Framework, which will break COM clients that expect a specific layout. Note that if the <xref:System.Runtime.InteropServices.StructLayoutAttribute> attribute is not specified, the C#, [!INCLUDE[vbprvb](../code-quality/includes/vbprvb_md.md)], and C++ compilers specify the <xref:System.Runtime.InteropServices.LayoutKind> layout for value types.
34
+
A Component Object Model (COM) visible value type is marked with the <xref:System.Runtime.InteropServices.StructLayoutAttribute?displayProperty=fullName> attribute set to <xref:System.Runtime.InteropServices.LayoutKind.Auto?displayProperty=fullName>.
35
+
36
+
## Rule description
37
+
38
+
<xref:System.Runtime.InteropServices.LayoutKind> layout types are managed by the common language runtime. The layout of these types can change between versions of the .NET Framework, which breaks COM clients that expect a specific layout. If the <xref:System.Runtime.InteropServices.StructLayoutAttribute> attribute is not specified, the C#, Visual Basic, and C++ compilers specify [LayoutKind.Auto](<xref:System.Runtime.InteropServices.LayoutKind.Auto>) for value types.
39
+
40
+
Unless marked otherwise, all public, non-generic types are visible to COM, and all non-public and generic types are invisible to COM. However, to reduce false positives, this rule requires the COM visibility of the type to be explicitly stated. The containing assembly must be marked with the <xref:System.Runtime.InteropServices.ComVisibleAttribute?displayProperty=fullName> set to `false` and the type must be marked with the <xref:System.Runtime.InteropServices.ComVisibleAttribute> set to `true`.
33
41
34
-
Unless marked otherwise, all public nongeneric types are visible to COM; all nonpublic and generic types are invisible to COM. However, to reduce false positives, this rule requires the COM visibility of the type to be explicitly stated; the containing assembly must be marked with the <xref:System.Runtime.InteropServices.ComVisibleAttribute?displayProperty=fullName> set to `false` and the type must be marked with the <xref:System.Runtime.InteropServices.ComVisibleAttribute> set to `true`.
42
+
## How to fix violations
35
43
36
-
## How to Fix Violations
37
-
To fix a violation of this rule, change the value of the <xref:System.Runtime.InteropServices.StructLayoutAttribute> attribute to <xref:System.Runtime.InteropServices.LayoutKind> or <xref:System.Runtime.InteropServices.LayoutKind>, or make the type invisible to COM.
44
+
To fix a violation of this rule, change the value of the <xref:System.Runtime.InteropServices.StructLayoutAttribute> attribute to [LayoutKind.Explicit](<xref:System.Runtime.InteropServices.LayoutKind.Explicit>) or [LayoutKind.Sequential](<xref:System.Runtime.InteropServices.LayoutKind.Sequential>), or make the type invisible to COM.
38
45
39
-
## When to Suppress Warnings
40
-
Do not suppress a warning from this rule.
46
+
## When to suppress warnings
47
+
48
+
Do not suppress a warning from this rule.
41
49
42
50
## Example
43
-
The following example shows a type that violates the rule and a type that satisfies the rule.
Copy file name to clipboardExpand all lines: docs/code-quality/ca2001-avoid-calling-problematic-methods.md
+16-12Lines changed: 16 additions & 12 deletions
Original file line number
Diff line number
Diff line change
@@ -18,6 +18,7 @@ ms.workload:
18
18
- "multiple"
19
19
---
20
20
# CA2001: Avoid calling problematic methods
21
+
21
22
|||
22
23
|-|-|
23
24
|TypeName|AvoidCallingProblematicMethods|
@@ -26,26 +27,29 @@ ms.workload:
26
27
|Breaking Change|Non-breaking|
27
28
28
29
## Cause
29
-
A member calls a potentially dangerous or problematic method.
30
30
31
-
## Rule Description
32
-
Avoid making unnecessary and potentially dangerous method calls.
31
+
A member calls a potentially dangerous or problematic method.
32
+
33
+
## Rule description
33
34
34
-
A violation of this rule occurs when a member calls one of the following methods.
35
+
Avoid making unnecessary and potentially dangerous method calls. A violation of this rule occurs when a member calls one of the following methods:
35
36
36
37
|Method|Description|
37
38
|------------|-----------------|
38
-
|<xref:System.GC.Collect%2A?displayProperty=fullName>|Calling GC.Collect can significantly affect application performance and is rarely necessary. For more information, see the [Rico Mariani's Performance Tidbits](http://go.microsoft.com/fwlink/?LinkId=169256) blog entry on MSDN.|
39
-
|<xref:System.Threading.Thread.Resume%2A?displayProperty=fullName><br /><br /> <xref:System.Threading.Thread.Suspend%2A?displayProperty=fullName>|Thread.Suspend and Thread.Resume have been deprecated because of their unpredictable behavior. Use other classes in the <xref:System.Threading> namespace, such as <xref:System.Threading.Monitor>, <xref:System.Threading.Mutex>, <xref:System.Threading.Mutex>, and <xref:System.Threading.Semaphore> to synchronize threads or protect resources.|
39
+
|<xref:System.GC.Collect%2A?displayProperty=fullName>|Calling GC.Collect can significantly affect application performance and is rarely necessary. For more information, see [Rico Mariani's Performance Tidbits](http://go.microsoft.com/fwlink/?LinkId=169256) blog entry on MSDN.|
40
+
|<xref:System.Threading.Thread.Resume%2A?displayProperty=fullName><br /><br /> <xref:System.Threading.Thread.Suspend%2A?displayProperty=fullName>|Thread.Suspend and Thread.Resume have been deprecated because of their unpredictable behavior. Use other classes in the <xref:System.Threading> namespace, such as <xref:System.Threading.Monitor>, <xref:System.Threading.Mutex>, and <xref:System.Threading.Semaphore>, to synchronize threads or protect resources.|
40
41
|<xref:System.Runtime.InteropServices.SafeHandle.DangerousGetHandle%2A?displayProperty=fullName>|The DangerousGetHandle method poses a security risk because it can return a handle that is not valid. See the <xref:System.Runtime.InteropServices.SafeHandle.DangerousAddRef%2A> and the <xref:System.Runtime.InteropServices.SafeHandle.DangerousRelease%2A> methods for more information about how to use the DangerousGetHandle method safely.|
41
42
|<xref:System.Reflection.Assembly.LoadFrom%2A?displayProperty=fullName><br /><br /> <xref:System.Reflection.Assembly.LoadFile%2A?displayProperty=fullName><br /><br /> <xref:System.Reflection.Assembly.LoadWithPartialName%2A?displayProperty=fullName>|These methods can load assemblies from unexpected locations. For example, see Suzanne Cook's .NET CLR Notes blog posts [LoadFile vs. LoadFrom](http://go.microsoft.com/fwlink/?LinkId=164450) and [Choosing a Binding Context](http://go.microsoft.com/fwlink/?LinkId=164451) on the MSDN Web site for information about methods that load assemblies.|
42
43
|[CoSetProxyBlanket](http://go.microsoft.com/fwlink/?LinkID=169250) (Ole32)<br /><br /> [CoInitializeSecurity](http://go.microsoft.com/fwlink/?LinkId=169255) (Ole32)|By the time the user code starts executing in a managed process, it is too late to reliably call CoSetProxyBlanket. The common language runtime (CLR) takes initialization actions that may prevent the users P/Invoke from succeeding.<br /><br /> If you do have to call CoSetProxyBlanket for a managed application, we recommend that you start the process by using a native code (C++) executable, call CoSetProxyBlanket in the native code, and then start your managed code application in process. (Be sure to specify a runtime version number.)|
43
44
44
-
## How to Fix Violations
45
-
To fix a violation of this rule, remove or replace the call to the dangerous or problematic method.
45
+
## How to fix violations
46
+
47
+
To fix a violation of this rule, remove or replace the call to the dangerous or problematic method.
48
+
49
+
## When to suppress warnings
50
+
51
+
You should suppress messages from this rule only when no alternatives to the problematic method are available.
46
52
47
-
## When to Suppress Warnings
48
-
You should suppress messages from this rule only when no alternatives to the problematic method are available.
0 commit comments