org.sonar.plugins.csharp.fxcop.rules.rules-unit-tests.xml Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of sonar-dotnet-fxcop-plugin Show documentation
Show all versions of sonar-dotnet-fxcop-plugin Show documentation
Plugin that runs FxCop analyses to check .NET assemblies against rule violations.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<rules>
<rule key="DoNotDeclareStaticMembersOnGenericTypes">
<name><![CDATA[Do not declare static members on generic types]]></name>
<configKey><![CDATA[DoNotDeclareStaticMembersOnGenericTypes@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[The syntax for calling static members on generic types is complex as the type parameter has to be specified for each call.<br/>
<a href="http://msdn.microsoft.com/library/ms182139(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TypesThatOwnDisposableFieldsShouldBeDisposable">
<name><![CDATA[Types that own disposable fields should be disposable]]></name>
<configKey><![CDATA[TypesThatOwnDisposableFieldsShouldBeDisposable@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Types that declare disposable members should also implement IDisposable. If the type does not own any unmanaged resources, do not implement a finalizer on it.<br/>
<a href="http://msdn.microsoft.com/library/ms182172(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotExposeGenericLists">
<name><![CDATA[Do not expose generic lists]]></name>
<configKey><![CDATA[DoNotExposeGenericLists@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Do not expose List<T> in object models. Use Collection<T>, ReadOnlyCollection<T> or KeyedCollection<K,V> instead. List<T> is meant to be used from implementation, not in object model API. List<T> is optimized for performance at the cost of long term versioning. For example, if you return List<T> to the client code, you will not ever be able to receive notifications when client code modifies the collection.<br/>
<a href="http://msdn.microsoft.com/library/ms182142(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="UseGenericEventHandlerInstances">
<name><![CDATA[Use generic event handler instances]]></name>
<configKey><![CDATA[UseGenericEventHandlerInstances@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Do not declare new delegates to be used as event handlers when targeting a version of the .NET Framework that supports generics. Use an instance EventHandler<T> instead.<br/>
<a href="http://msdn.microsoft.com/library/ms182178(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="GenericMethodsShouldProvideTypeParameter">
<name><![CDATA[Generic methods should provide type parameter]]></name>
<configKey><![CDATA[GenericMethodsShouldProvideTypeParameter@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Methods where the type parameter cannot be inferred from the parameters and therefore has to be defined in the method call are too difficult to understand. Methods with a formal parameter typed as the generic method type parameter support inference. Methods with no formal parameter typed as the generic method type parameter don't support inference.<br/>
<a href="http://msdn.microsoft.com/library/ms182150(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AvoidExcessiveParametersOnGenericTypes">
<name><![CDATA[Avoid excessive parameters on generic types]]></name>
<configKey><![CDATA[AvoidExcessiveParametersOnGenericTypes@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Avoid generic types with more than two type parameters as users have difficulties understanding what type parameters represent in types with long type parameter lists.<br/>
<a href="http://msdn.microsoft.com/library/ms182129(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotNestGenericTypesInMemberSignatures">
<name><![CDATA[Do not nest generic types in member signatures]]></name>
<configKey><![CDATA[DoNotNestGenericTypesInMemberSignatures@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Avoid API that require users to instantiate a generic type with another generic type as type argument. The syntax gets too complex.<br/>
<a href="http://msdn.microsoft.com/library/ms182144(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="UseGenericsWhereAppropriate">
<name><![CDATA[Use generics where appropriate]]></name>
<configKey><![CDATA[UseGenericsWhereAppropriate@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[References passed to ref parameters must be the exact type of the parameter. Using generics enable the method for general use.<br/>
<a href="http://msdn.microsoft.com/library/ms182179(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="EnumsShouldHaveZeroValue">
<name><![CDATA[Enums should have zero value]]></name>
<configKey><![CDATA[EnumsShouldHaveZeroValue@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[An enum should generally have a zero value. If the enum is not decorated with the Flags attribute, it should have a member with a value of zero that represents the empty state. Optionally, this value is named 'None'. For a Flags-attributed enum, a zero-valued member is optional and, if it exists, should always be named 'None'. This value should indicate that no values have been set in the enum. Using a zero-valued member for other purposes is contrary to the use of the Flags attribute in that the bitwise AND and OR operators are useless with the member.<br/>
<a href="http://msdn.microsoft.com/library/ms182149(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DeclareEventHandlersCorrectly">
<name><![CDATA[Declare event handlers correctly]]></name>
<configKey><![CDATA[DeclareEventHandlersCorrectly@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[By convention, .NET events have two parameters that specify the event sender and event data. Event handler signatures should follow this form: void MyEventHandler(object sender, EventArgs e). The 'sender' parameter is always of type System.Object, even if it is possible to employ a more specific type. The 'e' parameter is always of type System.EventArgs. Events that do not provide event data should use the System.EventHandler delegate type. Event handlers return void so that they can send each event to multiple target methods. Any value returned by a target would be lost after the first call.<br/>
<a href="http://msdn.microsoft.com/library/ms182133(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="CollectionsShouldImplementGenericInterface">
<name><![CDATA[Collections should implement generic interface]]></name>
<configKey><![CDATA[CollectionsShouldImplementGenericInterface@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Non-generic strongly typed collections should implement one of the generic collection interfaces. This will allow better integration of the collection with generic API.<br/>
<a href="http://msdn.microsoft.com/library/ms182132(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ConsiderPassingBaseTypesAsParameters">
<name><![CDATA[Consider passing base types as parameters]]></name>
<configKey><![CDATA[ConsiderPassingBaseTypesAsParameters@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Using base types as parameters to methods improves re-use of these methods if you only use methods & properties from the parameter's base class. E.g. use Stream instead of FileStream as a parameter when only calling Stream.Read(), this makes the method work on all kind of streams instead of just File streams.<br/>
<a href="http://msdn.microsoft.com/library/3hk32yyz(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AbstractTypesShouldNotHaveConstructors">
<name><![CDATA[Abstract types should not have constructors (FxCop10)]]></name>
<configKey><![CDATA[AbstractTypesShouldNotHaveConstructors@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Public constructors for abstract types do not make sense because you cannot create instances of abstract types.<br/>
<a href="http://msdn.microsoft.com/library/ms182126(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="OverloadOperatorEqualsOnOverloadingAddAndSubtract">
<name><![CDATA[Overload operator equals on overloading add and subtract]]></name>
<configKey><![CDATA[OverloadOperatorEqualsOnOverloadingAddAndSubtract@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[When overloading the addition and subtraction operators, make sure that the equality operator (==) is defined in a consistent manner.<br/>
<a href="http://msdn.microsoft.com/library/ms182164(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MarkAssembliesWithClsCompliant">
<name><![CDATA[Mark assemblies with CLSCompliantAttribute (FxCop10)]]></name>
<configKey><![CDATA[MarkAssembliesWithClsCompliant@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Assemblies should explicitly state their CLS compliance using the CLSCompliant attribute. An assembly without this attribute is not CLS-compliant. Assemblies, modules, and types can be CLS-compliant even if some parts of the assembly, module, or type are not CLS-compliant. The following rules apply: 1) If the element is marked CLSCompliant, any noncompliant members must have the CLSCompliant attribute present with its argument set to false. 2) A comparable CLS-compliant alternative member must be supplied for each member that is not CLS-compliant.<br/>
<a href="http://msdn.microsoft.com/library/ms182156(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AssembliesShouldHaveValidStrongNames">
<name><![CDATA[Assemblies should have valid strong names]]></name>
<configKey><![CDATA[AssembliesShouldHaveValidStrongNames@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Either the assembly has no strong name, an invalid one, or the strong name is valid only because of the computer configuration. The assembly should not be deployed in this state. The most common causes of this are: 1) The assembly's contents were modified after it was signed. 2) The signing process failed. 3) The assembly was delay-signed. 4) A registry key existed that allowed the check to pass (where it would not have otherwise).<br/>
<a href="http://msdn.microsoft.com/library/ms182127(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MarkAssembliesWithAssemblyVersion">
<name><![CDATA[Mark assemblies with AssemblyVersionAttribute (FxCop10)]]></name>
<configKey><![CDATA[MarkAssembliesWithAssemblyVersion@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Assemblies should use version numbers. The version number is considered part of an assembly's identity. Versioning is applied by means of the AssemblyVersion attribute.<br/>
<a href="http://msdn.microsoft.com/library/ms182155(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MarkAssembliesWithComVisible">
<name><![CDATA[Mark assemblies with ComVisibleAttribute (FxCop10)]]></name>
<configKey><![CDATA[MarkAssembliesWithComVisible@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[The System.Runtime.InteropServices.ComVisible attribute indicates whether COM clients can use the library. Good design dictates that developers explicitly indicate COM visibility. The default value for this attribute is 'true'. However, the best design is to mark the assembly ComVisible false, and then mark types, interfaces, and individual members as ComVisible true, as appropriate.<br/>
<a href="http://msdn.microsoft.com/library/ms182157(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MarkAttributesWithAttributeUsage">
<name><![CDATA[Mark attributes with AttributeUsageAttribute (FxCop10)]]></name>
<configKey><![CDATA[MarkAttributesWithAttributeUsage@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[The AttributeUsage attribute specifies the targets that are valid for the attribute (see System.AttributeTargets), whether an attribute can appear on a target more than once, and whether the attribute is inheritable.<br/>
<a href="http://msdn.microsoft.com/library/ms182158(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DefineAccessorsForAttributeArguments">
<name><![CDATA[Define accessors for attribute arguments]]></name>
<configKey><![CDATA[DefineAccessorsForAttributeArguments@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Provide accessors for both named and positional arguments. Each positional argument on an attribute should declare a read-only property with the same name (but different casing). Each named argument should provide a read/write property with the same name (but different casing).<br/>
<a href="http://msdn.microsoft.com/library/ms182136(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AvoidNamespacesWithFewTypes">
<name><![CDATA[Avoid namespaces with few types]]></name>
<configKey><![CDATA[AvoidNamespacesWithFewTypes@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[A namespace should generally have more than five types.<br/>
<a href="http://msdn.microsoft.com/library/ms182130(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AvoidOutParameters">
<name><![CDATA[Avoid out parameters]]></name>
<configKey><![CDATA[AvoidOutParameters@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Using out parameters might indicate a design flaw. Although there are legitimate times to use out parameters, their use frequently indicates a design that does not conform to the design guidelines for managed code.<br/>
<a href="http://msdn.microsoft.com/library/ms182131(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="IndexersShouldNotBeMultidimensional">
<name><![CDATA[Indexers should not be multidimensional]]></name>
<configKey><![CDATA[IndexersShouldNotBeMultidimensional@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Indexers (indexed properties) should use a single value (either an integer or string types) for indexing values. Multidimensional indexers can significantly reduce the usability of the library. For example, public object this [int index1, int index2] is a non-intuitive indexer.<br/>
<a href="http://msdn.microsoft.com/library/ms182152(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="UsePropertiesWhereAppropriate">
<name><![CDATA[Use properties where appropriate]]></name>
<configKey><![CDATA[UsePropertiesWhereAppropriate@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Properties should be used instead of Get/Set methods in most situations. Methods are preferable to properties in the following situations: the operation is a conversion, is expensive or has an observable side-effect; the order of execution is important; calling the member twice in succession creates different results; a member is static but returns a mutable value; or the member returns an array.<br/>
<a href="http://msdn.microsoft.com/library/ms182181(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ReplaceRepetitiveArgumentsWithParamsArray">
<name><![CDATA[Replace repetitive arguments with params array]]></name>
<configKey><![CDATA[ReplaceRepetitiveArgumentsWithParamsArray@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Several instances of same-type arguments can be better implemented as a parameter array argument. Generally, if a member declares three or more arguments of the same type, consider using a parameter array.<br/>
<a href="http://msdn.microsoft.com/library/ms182167(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DefaultParametersShouldNotBeUsed">
<name><![CDATA[Default parameters should not be used]]></name>
<configKey><![CDATA[DefaultParametersShouldNotBeUsed@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Some programming languages do not support default parameters. Replace default parameters with method overloads that supply the default argument.<br/>
<a href="http://msdn.microsoft.com/library/ms182135(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MarkEnumsWithFlags">
<name><![CDATA[Mark enums with FlagsAttribute]]></name>
<configKey><![CDATA[MarkEnumsWithFlags@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[The enumeration appears to be made up of combinable flags. If this true, apply the Flags attribute to the enumeration.<br/>
<a href="http://msdn.microsoft.com/library/ms182159(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="EnumStorageShouldBeInt32">
<name><![CDATA[Enum storage should be Int32]]></name>
<configKey><![CDATA[EnumStorageShouldBeInt32@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[There is little or no benefit to using a type smaller than Int32. You might require a type that is larger than Int32 if: 1) the enumeration values are flags and there are or will be many (&amp;gt;32) values, or 2) the type needs to be different from Int32 for backward compatibility. Avoid using an underlying type that is not integral.<br/>
<a href="http://msdn.microsoft.com/library/ms182147(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="UseEventsWhereAppropriate">
<name><![CDATA[Use events where appropriate]]></name>
<configKey><![CDATA[UseEventsWhereAppropriate@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[A method name suggestive of event functionality was encountered.<br/>
<a href="http://msdn.microsoft.com/library/ms182177(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotCatchGeneralExceptionTypes">
<name><![CDATA[Do not catch general exception types]]></name>
<configKey><![CDATA[DoNotCatchGeneralExceptionTypes@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[You should not catch Exception or SystemException. Catching generic exception types can hide run-time problems from the library user, and can complicate debugging. You should catch only those exceptions that you can handle gracefully.<br/>
<a href="http://msdn.microsoft.com/library/ms182137(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ImplementStandardExceptionConstructors">
<name><![CDATA[Implement standard exception constructors]]></name>
<configKey><![CDATA[ImplementStandardExceptionConstructors@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Multiple constructors are required to correctly implement a custom exception. Missing constructors can make your exception unusable in certain scenarios. For example, the serialization constructor is required for handling exceptions in XML Web services.<br/>
<a href="http://msdn.microsoft.com/library/ms182151(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="InterfaceMethodsShouldBeCallableByChildTypes">
<name><![CDATA[Interface methods should be callable by child types]]></name>
<configKey><![CDATA[InterfaceMethodsShouldBeCallableByChildTypes@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Explicit method implementations are defined with private accessibility. Classes that derive from classes with explicit method implementations and choose to re-declare them on the class will not be able to call into the base class implementation unless the base class has provided an alternate method with appropriate accessibility. When overriding a base class method that has been hidden by explicit interface implementation, in order to call into the base class implementation, a derived class must cast the base pointer to the relevant interface. When calling through this reference, however, the derived class implementation will actually be invoked, resulting in recursion and an eventual stack overflow.<br/>
<a href="http://msdn.microsoft.com/library/ms182153(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="NestedTypesShouldNotBeVisible">
<name><![CDATA[Nested types should not be visible]]></name>
<configKey><![CDATA[NestedTypesShouldNotBeVisible@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Do not use public, protected or protected internal (Protected Friend) nested types as a way of grouping types. Use namespaces for this purpose. There are very limited scenarios where nested types are the best design. Also, nested type member accessibility is not clearly understood by all audiences. Enumerators are exempt from this rule.<br/>
<a href="http://msdn.microsoft.com/library/ms182162(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ICollectionImplementationsHaveStronglyTypedMembers">
<name><![CDATA[ICollection implementations have strongly typed members]]></name>
<configKey><![CDATA[ICollectionImplementationsHaveStronglyTypedMembers@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Types that implement ICollection should also provide a version of CopyTo with the first parameter set to a strong type, namely a type other than an array of objects or System.Array. Implement the interface member explicitly and make the strongly typed version public. It is safe to ignore violations of this rule when you are implementing a new object-based collection, such as a binary tree, where types based on your collection will determine what the strong type is. These types should expose strongly typed members.<br/>
<a href="http://msdn.microsoft.com/library/49stb304(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="OverrideMethodsOnComparableTypes">
<name><![CDATA[Override methods on comparable types]]></name>
<configKey><![CDATA[OverrideMethodsOnComparableTypes@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Types that implement IComparable should redefine Equals and comparison operators to keep the meanings of less than, greater than, and equals consistent throughout the type.<br/>
<a href="http://msdn.microsoft.com/library/ms182163(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="EnumeratorsShouldBeStronglyTyped">
<name><![CDATA[Enumerators should be strongly typed]]></name>
<configKey><![CDATA[EnumeratorsShouldBeStronglyTyped@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Types that implement IEnumerator should also provide a version of the Current property that returns a type other than Object. Implement the interface member explicitly and make the strongly typed version public.<br/>
<a href="http://msdn.microsoft.com/library/ms182148(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ListsAreStronglyTyped">
<name><![CDATA[Lists are strongly typed]]></name>
<configKey><![CDATA[ListsAreStronglyTyped@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[IList implementations should also provide versions of the IList members that are strongly typed, namely they should specify types other than Object for method and property parameter and return types. Implement the interface members explicitly and make the strongly typed versions public. It is safe to ignore violations of this rule when you are implementing a new object-based collection, such as a linked list, where types based on your collection will determine what the strong type is. These types should expose strongly typed members.<br/>
<a href="http://msdn.microsoft.com/library/ms182154(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AvoidEmptyInterfaces">
<name><![CDATA[Avoid empty interfaces]]></name>
<configKey><![CDATA[AvoidEmptyInterfaces@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Interfaces are meant to contain members that specify a set of behaviors. To mark or label a class, use an attribute instead of an empty interface.<br/>
<a href="http://msdn.microsoft.com/library/ms182128(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ProvideObsoleteAttributeMessage">
<name><![CDATA[Provide ObsoleteAttribute message]]></name>
<configKey><![CDATA[ProvideObsoleteAttributeMessage@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[The ObsoleteAttribute.Message property provides the text message displayed when an obsolete type or member is compiled. This message should provide information on the replacement for the obsolete element.<br/>
<a href="http://msdn.microsoft.com/library/ms182166(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="UseIntegralOrStringArgumentForIndexers">
<name><![CDATA[Use integral or string argument for indexers]]></name>
<configKey><![CDATA[UseIntegralOrStringArgumentForIndexers@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Indexers (indexed properties) should use either integer or string types for indexing values. These types are easy to use and commonly used for indexing data structures; using other types can significantly reduce the usability of the library. For example, public char this [int index] is the C# signature for the String type's indexer.<br/>
<a href="http://msdn.microsoft.com/library/ms182180(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="PropertiesShouldNotBeWriteOnly">
<name><![CDATA[Properties should not be write only]]></name>
<configKey><![CDATA[PropertiesShouldNotBeWriteOnly@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Write-only properties usually indicate a flawed design.<br/>
<a href="http://msdn.microsoft.com/library/ms182165(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotPassTypesByReference">
<name><![CDATA[Do not pass types by reference]]></name>
<configKey><![CDATA[DoNotPassTypesByReference@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Although there are legitimate times to use reference parameters, such use frequently indicates a design that does not conform to the design guidelines for managed code.<br/>
<a href="http://msdn.microsoft.com/library/ms182146(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotOverloadOperatorEqualsOnReferenceTypes">
<name><![CDATA[Do not overload operator equals on reference types]]></name>
<configKey><![CDATA[DoNotOverloadOperatorEqualsOnReferenceTypes@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Most reference types, including those that override System.Object.Equals, do not override the equality operator (==). Most languages provide a default implementation of this operator.<br/>
<a href="http://msdn.microsoft.com/library/ms182145(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotDeclareProtectedMembersInSealedTypes">
<name><![CDATA[Do not declare protected members in sealed types]]></name>
<configKey><![CDATA[DoNotDeclareProtectedMembersInSealedTypes@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Sealed types cannot be extended, and protected members are only useful if you can extend the declaring type. Sealed types should not declare protected members.<br/>
<a href="http://msdn.microsoft.com/library/ms182138(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotDeclareVirtualMembersInSealedTypes">
<name><![CDATA[Do not declare virtual members in sealed types]]></name>
<configKey><![CDATA[DoNotDeclareVirtualMembersInSealedTypes@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Sealed types cannot be extended, and virtual members are only useful if you can extend the declaring type.<br/>
<a href="http://msdn.microsoft.com/library/ms182140(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TypesThatOwnNativeResourcesShouldBeDisposable">
<name><![CDATA[Types that own native resources should be disposable]]></name>
<configKey><![CDATA[TypesThatOwnNativeResourcesShouldBeDisposable@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Types that allocate unmanaged resources should implement IDisposable to allow callers to release those resources on demand. Failure to implement IDisposable can result in unmanaged resources being unavailable or underutilized.<br/>
<a href="http://msdn.microsoft.com/library/ms182173(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DeclareTypesInNamespaces">
<name><![CDATA[Declare types in namespaces]]></name>
<configKey><![CDATA[DeclareTypesInNamespaces@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[A type should be defined inside a namespace to avoid duplication.<br/>
<a href="http://msdn.microsoft.com/library/ms182134(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotDeclareVisibleInstanceFields">
<name><![CDATA[Do not declare visible instance fields]]></name>
<configKey><![CDATA[DoNotDeclareVisibleInstanceFields@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Instance fields that are visible outside of the type that declares them, limit your ability to change the implementation details for those data items. Use properties instead. They do not compromise usability or performance and they do provide flexibility in that they conceal the implementation details of the underlying data.<br/>
<a href="http://msdn.microsoft.com/library/ms182141(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="StaticHolderTypesShouldBeSealed">
<name><![CDATA[Static holder types should be sealed]]></name>
<configKey><![CDATA[StaticHolderTypesShouldBeSealed@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Static holder types do not provide functionality that derived instances can extend. Inheriting from such a type indicates a flawed design.<br/>
<a href="http://msdn.microsoft.com/library/ms182168(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="StaticHolderTypesShouldNotHaveConstructors">
<name><![CDATA[Static holder types should not have constructors]]></name>
<configKey><![CDATA[StaticHolderTypesShouldNotHaveConstructors@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Instances of types that define only static members do not need to be created. Many compilers will automatically add a public default constructor if no constructor is specified. To prevent this, adding an empty private constructor may be required.<br/>
<a href="http://msdn.microsoft.com/library/ms182169(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="UriParametersShouldNotBeStrings">
<name><![CDATA[URI parameters should not be strings]]></name>
<configKey><![CDATA[UriParametersShouldNotBeStrings@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[If a parameter name contains "uri" or "url" or "urn", and it's typed as string, the parameter type should be changed to System.Uri, unless there is an overload method where the same parameter is typed as System.Uri.<br/>
<a href="http://msdn.microsoft.com/library/ms182174(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="UriReturnValuesShouldNotBeStrings">
<name><![CDATA[URI return values should not be strings]]></name>
<configKey><![CDATA[UriReturnValuesShouldNotBeStrings@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[If a function name contains "uri" or "url" or "urn" and the return type is string, the return type should be changed to System.Uri.<br/>
<a href="http://msdn.microsoft.com/library/ms182176(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="UriPropertiesShouldNotBeStrings">
<name><![CDATA[URI properties should not be strings]]></name>
<configKey><![CDATA[UriPropertiesShouldNotBeStrings@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[If a property name contains "uri" or "url" or "urn" and it's typed as string, it should be changed to System.Uri.<br/>
<a href="http://msdn.microsoft.com/library/ms182175(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="StringUriOverloadsCallSystemUriOverloads">
<name><![CDATA[String URI overloads call System.Uri overloads]]></name>
<configKey><![CDATA[StringUriOverloadsCallSystemUriOverloads@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[If a method overloads another method by replacing a System.Uri parameter with a string, then the string overload should simply build a Uri object from the string, and pass the result to the string overload.<br/>
<a href="http://msdn.microsoft.com/library/ms182170(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TypesShouldNotExtendCertainBaseTypes">
<name><![CDATA[Types should not extend certain base types]]></name>
<configKey><![CDATA[TypesShouldNotExtendCertainBaseTypes@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[It is best not to extend some base types or to prefer extending better alternatives to those base types.<br/>
<a href="http://msdn.microsoft.com/library/ms182171(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MembersShouldNotExposeCertainConcreteTypes">
<name><![CDATA[Members should not expose certain concrete types]]></name>
<configKey><![CDATA[MembersShouldNotExposeCertainConcreteTypes@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Members should not expose certain concrete types.<br/>
<a href="http://msdn.microsoft.com/library/ms182160(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MovePInvokesToNativeMethodsClass">
<name><![CDATA[Move P/Invokes to NativeMethods class]]></name>
<configKey><![CDATA[MovePInvokesToNativeMethodsClass@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[This type contains members with the DllImport attribute. Members with the DllImport attribute should be contained in classes named NativeMethods, SafeNativeMethods, or UnsafeNativeMethods.<br/>
<a href="http://msdn.microsoft.com/library/ms182161(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotHideBaseClassMethods">
<name><![CDATA[Do not hide base class methods]]></name>
<configKey><![CDATA[DoNotHideBaseClassMethods@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Defining a method in a derived class with the same name and parameters that are more weakly typed as one that is defined in the base class will obstruct access to the method defined in the base class.<br/>
<a href="http://msdn.microsoft.com/library/ms182143(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ImplementIDisposableCorrectly">
<name><![CDATA[Implement IDisposable correctly]]></name>
<configKey><![CDATA[ImplementIDisposableCorrectly@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[All IDisposable types should implement the Dispose pattern correctly.<br/>
<a href="http://msdn.microsoft.com/library/ms244737(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ExceptionsShouldBePublic">
<name><![CDATA[Exceptions should be public]]></name>
<configKey><![CDATA[ExceptionsShouldBePublic@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Exception classes should either be public, or have a non-generic public ancestor.<br/>
<a href="http://msdn.microsoft.com/library/bb264484(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotRaiseExceptionsInUnexpectedLocations">
<name><![CDATA[Do not raise exceptions in unexpected locations]]></name>
<configKey><![CDATA[DoNotRaiseExceptionsInUnexpectedLocations@$(FxCopDir)\Rules\DesignRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Do not explicitly raise exceptions from unexpected locations. There are some methods, such as Equals and GetHashCode, which users do not expect to raise exceptions. Therefore calls to these methods are not commonly wrapped in try catch blocks.<br/>
<a href="http://msdn.microsoft.com/library/bb386039(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="SpecifyMessageBoxOptions">
<name><![CDATA[Specify MessageBoxOptions (FxCop10)]]></name>
<configKey><![CDATA[SpecifyMessageBoxOptions@$(FxCopDir)\Rules\GlobalizationRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[In order to run correctly on right-to-left systems, all calls to MessageBox.Show should use the overload that specifies MessageBoxOptions as an argument. Programs should detect whether they are running on a right-to-left system at run-time and pass the appropriate MessageBoxOptions value in order to display correctly.<br/>
<a href="http://msdn.microsoft.com/library/ms182191(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AvoidDuplicateAccelerators">
<name><![CDATA[Avoid duplicate accelerators]]></name>
<configKey><![CDATA[AvoidDuplicateAccelerators@$(FxCopDir)\Rules\GlobalizationRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Controls should have unique accelerators for all items and sub-controls.<br/>
<a href="http://msdn.microsoft.com/library/ms182185(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotHardcodeLocaleSpecificStrings">
<name><![CDATA[Do not hardcode locale specific strings]]></name>
<configKey><![CDATA[DoNotHardcodeLocaleSpecificStrings@$(FxCopDir)\Rules\GlobalizationRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Do not use string literals for system items that have locale-specific designations. Special system locations should be retrieved using provided API such as GetFolderPath. See the System.Environment.SpecialFolder enumeration for more information.<br/>
<a href="http://msdn.microsoft.com/library/ms182186(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="SpecifyCultureInfo">
<name><![CDATA[Specify CultureInfo (FxCop10)]]></name>
<configKey><![CDATA[SpecifyCultureInfo@$(FxCopDir)\Rules\GlobalizationRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[If an overload exists that takes a CultureInfo argument, it should always be called in favor of an overload that does not. The CultureInfo type contains culture-specific information required for performing numeric and string operations, such as casing, formatting, and string comparisons. In scenarios where conversion and parsing behavior should never change between cultures, specify CultureInfo.InvariantCulture, otherwise, specify CultureInfo.CurrentCulture.<br/>
<a href="http://msdn.microsoft.com/library/ms182189(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="SpecifyIFormatProvider">
<name><![CDATA[Specify IFormatProvider]]></name>
<configKey><![CDATA[SpecifyIFormatProvider@$(FxCopDir)\Rules\GlobalizationRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[If an overload exists that takes an IFormatProvider argument, it should always be called in favor of an overload that does not. Some methods in the runtime convert a value to or from a string representation and take a string parameter that contains one or more characters, called format specifiers, which indicate how the value is to be converted. If the meaning of the format specifier varies by culture, a formatting object supplies the actual characters used in the string representation. In scenarios where sorting and comparison behavior should never change between cultures, specify CultureInfo.InvariantCulture, otherwise, specify CultureInfo.CurrentCulture.<br/>
<a href="http://msdn.microsoft.com/library/ms182190(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="SetLocaleForDataTypes">
<name><![CDATA[Set locale for data types]]></name>
<configKey><![CDATA[SetLocaleForDataTypes@$(FxCopDir)\Rules\GlobalizationRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[In most cases, Locale should be explicitly set to CultureInfo.InvariantCulture on DataSet and DataTable instances. Upon creation of a DataSet or DataTable instance, the Locale is set to the current culture. In most cases, the Locale should be set to CultureInfo.InvariantCulture to guarantee proper sorting behavior in all cultures.<br/>
<a href="http://msdn.microsoft.com/library/ms182188(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="SpecifyMarshalingForPInvokeStringArguments">
<name><![CDATA[Specify marshaling for P/Invoke string arguments]]></name>
<configKey><![CDATA[SpecifyMarshalingForPInvokeStringArguments@$(FxCopDir)\Rules\GlobalizationRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[When marshaling strings as ANSI (or as Auto on Win9x), some characters may be changed. If best-fit mapping is on, strings that appear different in Unicode will be marshaled to identical ANSI strings, which may lead to incorrect security decisions. Turning best-fit mapping off reduces this risk, as all characters without equivalents are mapped to '?'. Also, note that CharSet.Ansi is the default setting for all string marshaling; Unicode marshaling must be specified explicitly, either as a CharSet setting of DllImport or StructLayout, or as a MarshalAs attribute with a Unicode (or system-dependent) UnmanagedType.<br/>
<a href="http://msdn.microsoft.com/library/ms182319(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="SpecifyStringComparison">
<name><![CDATA[Specify StringComparison]]></name>
<configKey><![CDATA[SpecifyStringComparison@$(FxCopDir)\Rules\GlobalizationRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[If an overload exists that takes a StringComparison argument, it should always be called in favor of an overload that does not.<br/>
<a href="http://msdn.microsoft.com/library/bb386080(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="NormalizeStringsToUppercase">
<name><![CDATA[Normalize strings to uppercase]]></name>
<configKey><![CDATA[NormalizeStringsToUppercase@$(FxCopDir)\Rules\GlobalizationRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Strings should be normalized to upper-case.<br/>
<a href="http://msdn.microsoft.com/library/bb386042(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="UseOrdinalStringComparison">
<name><![CDATA[Use ordinal StringComparison]]></name>
<configKey><![CDATA[UseOrdinalStringComparison@$(FxCopDir)\Rules\GlobalizationRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[For non-linguistic comparisons, StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase should be used instead of the linguistically-sensitive StringComparison.InvariantCulture.<br/>
<a href="http://msdn.microsoft.com/library/bb385972(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="PInvokeEntryPointsShouldExist">
<name><![CDATA[P/Invoke entry points should exist (FxCop10)]]></name>
<configKey><![CDATA[PInvokeEntryPointsShouldExist@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Methods decorated with the DllImport attribute should point to existing unmanaged entry points. There is no compile-time check to ensure that methods decorated with the DllImport attribute actually exist in the referenced unmanaged dll. In the event that an entry point does not exist or the specified argument list is not correct, a runtime exception will be generated.<br/>
<a href="http://msdn.microsoft.com/library/ms182208(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="PInvokesShouldNotBeVisible">
<name><![CDATA[P/Invokes should not be visible (FxCop10)]]></name>
<configKey><![CDATA[PInvokesShouldNotBeVisible@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Interop layer should not be public. The DllImport attribute should not be applied to publicly accessible members (public or protected).<br/>
<a href="http://msdn.microsoft.com/library/ms182209(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AvoidOverloadsInComVisibleInterfaces">
<name><![CDATA[Avoid overloads in COM visible interfaces (FxCop10)]]></name>
<configKey><![CDATA[AvoidOverloadsInComVisibleInterfaces@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Interfaces that are visible to COM should not define overloads, as they will be renamed and cannot be implemented by Visual Basic 6 clients. COM interfaces cannot contain overloaded methods.<br/>
<a href="http://msdn.microsoft.com/library/ms182197(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AutoLayoutTypesShouldNotBeComVisible">
<name><![CDATA[Auto layout types should not be COM visible (FxCop10)]]></name>
<configKey><![CDATA[AutoLayoutTypesShouldNotBeComVisible@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Types that are automatically ordered by the runtime should not be visible to COM. Types that are automatically laid out by the runtime do not have a guaranteed order between versions. This can break COM clients of those types. To ensure compatibility between versions, the type should be explicitly or sequentially ordered.<br/>
<a href="http://msdn.microsoft.com/library/ms182194(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="CallGetLastErrorImmediatelyAfterPInvoke">
<name><![CDATA[Call GetLastError immediately after P/Invoke (FxCop10)]]></name>
<configKey><![CDATA[CallGetLastErrorImmediatelyAfterPInvoke@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[The last Win32 error can be reset as a result of making managed calls, due to P/Invokes called by the runtime itself. In order to ensure the correctness of the value returned by GetLastWin32Error, place the call immediately after the relevant platform invoke call in your code.<br/>
<a href="http://msdn.microsoft.com/library/ms182199(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ComVisibleTypeBaseTypesShouldBeComVisible">
<name><![CDATA[COM visible type base types should be COM visible (FxCop10)
]]></name>
<configKey><![CDATA[ComVisibleTypeBaseTypesShouldBeComVisible@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[COM visible types should have an object hierarchy that is uniformly COM visible.<br/>
<a href="http://msdn.microsoft.com/library/ms182202(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AvoidInt64ArgumentsForVB6Clients">
<name><![CDATA[Avoid Int64 arguments for Visual Basic 6 clients (FxCop10)
]]></name>
<configKey><![CDATA[AvoidInt64ArgumentsForVB6Clients@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[COM visible types that might be accessed from Microsoft Visual Basic 6 clients should not expose methods with long arguments.<br/>
<a href="http://msdn.microsoft.com/library/ms182195(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AvoidStaticMembersInComVisibleTypes">
<name><![CDATA[Avoid static members in COM visible types (FxCop10)]]></name>
<configKey><![CDATA[AvoidStaticMembersInComVisibleTypes@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[COM does not support static methods.<br/>
<a href="http://msdn.microsoft.com/library/ms182198(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotUseAutoDualClassInterfaceType">
<name><![CDATA[Do not use AutoDual ClassInterfaceType (FxCop10)]]></name>
<configKey><![CDATA[DoNotUseAutoDualClassInterfaceType@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Classes that use the ClassInterfaceType.AutoDual setting might break in later versions if you change the member layout of the class or base classes. ClassInterfaceType.AutoDual should only be used when the versioning limitations are known to be acceptable.<br/>
<a href="http://msdn.microsoft.com/library/ms182205(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ComVisibleTypesShouldBeCreatable">
<name><![CDATA[COM visible types should be creatable (FxCop10)]]></name>
<configKey><![CDATA[ComVisibleTypesShouldBeCreatable@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Types with no public default constructor are not COM-creatable. COM does not support parameterized object construction. A type was detected with a public parameterized constructor but no public default constructor. This type is not creatable by COM. If there is an alternate method for creating and passing object instances to COM clients (through a method on another type, for example), this might not be a problem.<br/>
<a href="http://msdn.microsoft.com/library/ms182203(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ComRegistrationMethodsShouldBeMatched">
<name><![CDATA[COM registration methods should be matched (FxCop10)]]></name>
<configKey><![CDATA[ComRegistrationMethodsShouldBeMatched@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[If a COM registration method is provided, an unregistration method must also be provided to reverse the operations performed by the registration method. COM registration functions are static methods within a type that are marked with the ComRegisterFunction attribute. All COM registration functions should be matched by a static method within the same type that is marked with the ComUnregisterFunction attribute. This method should reverse any operations completed by the registration function.<br/>
<a href="http://msdn.microsoft.com/library/ms182200(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ComRegistrationMethodsShouldNotBeVisible">
<name><![CDATA[COM registration methods should not be visible (FxCop10)]]></name>
<configKey><![CDATA[ComRegistrationMethodsShouldNotBeVisible@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[COM registration and unregistration functions should be private or internal. COM registration and unregistration functions are called by the runtime when an assembly is registered or unregistered for use with COM. It is preferred that these methods are not externally visible.<br/>
<a href="http://msdn.microsoft.com/library/ms182201(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MarkComSourceInterfacesAsIDispatch">
<name><![CDATA[Mark ComSource interfaces as IDispatch (FxCop10)]]></name>
<configKey><![CDATA[MarkComSourceInterfacesAsIDispatch@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[COM source interfaces should be marked ComInterfaceType.InterfaceIsIDispatch. Visual Basic 6 clients cannot receive events with non-IDispatch interfaces.<br/>
<a href="http://msdn.microsoft.com/library/ms182207(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AvoidNonpublicFieldsInComVisibleValueTypes">
<name><![CDATA[Avoid non-public fields in COM visible value types (FxCop10)
]]></name>
<configKey><![CDATA[AvoidNonpublicFieldsInComVisibleValueTypes@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[COM visible value types should not expose non-public instance fields. COM visible value types have their non-public instance fields exposed to COM clients.<br/>
<a href="http://msdn.microsoft.com/library/ms182196(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MarkBooleanPInvokeArgumentsWithMarshalAs">
<name><![CDATA[Mark boolean P/Invoke arguments with MarshalAs (FxCop10)]]></name>
<configKey><![CDATA[MarkBooleanPInvokeArgumentsWithMarshalAs@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[All boolean P/Invoke parameters and return types should be explicitly marked with the MarshalAs attribute. By default, the system will marshal all booleans as 4-byte UnmanagedType.Bool. This is the correct behavior for Win32 'BOOL' arguments but incorrect for C++ 'bool' arguments, which should be marshaled as 1-byte UnmanagedType.U1. For code maintainability reasons, always explicitly specify the marshaling information for boolean arguments and return values.<br/>
<a href="http://msdn.microsoft.com/library/ms182206(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DeclarePInvokesCorrectly">
<name><![CDATA[Declare P/Invokes correctly (FxCop10)]]></name>
<configKey><![CDATA[DeclarePInvokesCorrectly@$(FxCopDir)\Rules\InteroperabilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[P/Invoke methods should be declared correctly to ensure correct runtime behaviors.<br/>
<a href="http://msdn.microsoft.com/library/ms182204(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotUseIdleProcessPriority">
<name><![CDATA[Do not use idle process priority (FxCop10)]]></name>
<configKey><![CDATA[DoNotUseIdleProcessPriority@$(FxCopDir)\Rules\MobilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Do not set process priority to Idle. Processes with System.Diagnostics.ProcessPriorityClass.Idle will occupy the CPU when it would otherwise be idle, and thereby block standby.<br/>
<a href="http://msdn.microsoft.com/library/ms182219(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotUseTimersThatPreventPowerStateChanges">
<name><![CDATA[Do not use timers that prevent power state changes (FxCop10)
]]></name>
<configKey><![CDATA[DoNotUseTimersThatPreventPowerStateChanges@$(FxCopDir)\Rules\MobilityRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Do not poll more often than or utilize timers that fire more frequently than once per second. Higher frequency periodic activity will keep the CPU busy and interfere with power-saving idle timers that turn off the display and hard disks.<br/>
<a href="http://msdn.microsoft.com/library/ms182230(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotNameEnumValuesReserved">
<name><![CDATA[Do not name enum values 'Reserved']]></name>
<configKey><![CDATA[DoNotNameEnumValuesReserved@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Avoid naming an enum value 'Reserved'. Adding 'Reserved' values will lead to a breaking change on removal when the value is actually used in a later version of the product.<br/>
<a href="http://msdn.microsoft.com/library/ms182236(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ResourceStringCompoundWordsShouldBeCasedCorrectly">
<name><![CDATA[Resource string compound words should be cased correctly]]></name>
<configKey><![CDATA[ResourceStringCompoundWordsShouldBeCasedCorrectly@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Avoid creating compound words from terms which exist in the dictionary as discrete terms. Do not create a compound word such as 'StopWatch' or 'PopUp'. These terms are recognized in the dictionary and should be cased as 'Stopwatch' and 'Popup'.<br/>
<a href="http://msdn.microsoft.com/library/bb264481(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="CompoundWordsShouldBeCasedCorrectly">
<name><![CDATA[Compound words should be cased correctly]]></name>
<configKey><![CDATA[CompoundWordsShouldBeCasedCorrectly@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Avoid creating compound words from terms which exist in the dictionary as discrete terms. Do not create a compound word such as 'StopWatch' or 'PopUp'. These terms are recognized in the dictionary and should be cased as 'Stopwatch' and 'Popup'.<br/>
<a href="http://msdn.microsoft.com/library/bb264474(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ResourceStringsShouldBeSpelledCorrectly">
<name><![CDATA[Resource strings should be spelled correctly]]></name>
<configKey><![CDATA[ResourceStringsShouldBeSpelledCorrectly@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[The individual words that make up a resource string should not be abbreviated and should be spelled correctly. If this rule generates a false positive on a term that should be recognized, add the word to the FxCop custom dictionary.<br/>
<a href="http://msdn.microsoft.com/library/bb264483(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="IdentifiersShouldBeSpelledCorrectly">
<name><![CDATA[Identifiers should be spelled correctly (FxCop10)]]></name>
<configKey><![CDATA[IdentifiersShouldBeSpelledCorrectly@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[The individual words that make up an identifier should not be abbreviated and should be spelled correctly. If this rule generates a false positive on a term that should be recognized, add the word to the FxCop custom dictionary.<br/>
<a href="http://msdn.microsoft.com/library/bb264492(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="IdentifiersShouldNotContainUnderscores">
<name><![CDATA[Identifiers should not contain underscores (FxCop10)]]></name>
<configKey><![CDATA[IdentifiersShouldNotContainUnderscores@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Do not use underscores when specifying identifiers. Some generated Visual Studio identifiers for applications contain underscore characters. Underscore characters should generally be avoided in public identifiers.<br/>
<a href="http://msdn.microsoft.com/library/ms182245(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="IdentifiersShouldDifferByMoreThanCase">
<name><![CDATA[Identifiers should differ by more than case]]></name>
<configKey><![CDATA[IdentifiersShouldDifferByMoreThanCase@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Do not use names that require case sensitivity for uniqueness. Components must be fully usable from both case-sensitive and case-insensitive languages. Since case-insensitive languages cannot distinguish between two names within the same context that differ only by case, components must avoid this situation.<br/>
<a href="http://msdn.microsoft.com/library/ms182242(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="IdentifiersShouldBeCasedCorrectly">
<name><![CDATA[Identifiers should be cased correctly (FxCop10)]]></name>
<configKey><![CDATA[IdentifiersShouldBeCasedCorrectly@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Type, namespace, and member identifiers are Pascal-cased. Parameter identifiers are camel-cased. Two letter acronyms within these identifiers should be upper-cased, for example, use System.IO instead of System.Io. Acronyms of three or more letters should be Pascal-cased, for example, use System.Xml instead of System.XML. The pascal-casing convention capitalizes the first letter of each word, as in BackColor. The camel-casing convention formats the first letter of the first word in lowercase and capitalizes the first letter of all subsequent words, as in backgroundColor. Although it may be common practice for some two letter acronyms to not be fully capitalized, violations of this rule should not be excluded for this reason. For example, 'DbConnection', is common but incorrect; use DBConnection. A violation of this rule might be required for compatibility with existing, non-managed symbol schemes. In general, however, these symbols should not be visible outside the assembly that uses them.<br/>
<a href="http://msdn.microsoft.com/library/ms182240(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="IdentifiersShouldHaveCorrectSuffix">
<name><![CDATA[Identifiers should have correct suffix]]></name>
<configKey><![CDATA[IdentifiersShouldHaveCorrectSuffix@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Types that extend certain base types have specified name suffixes. Types that extend Attribute, for example, should be suffixed in 'Attribute', as in ObsoleteAttribute. This rules checks types that extend several base types, including Attribute, Exception, EventArgs, IMembershipPermission, Stream, and others.<br/>
<a href="http://msdn.microsoft.com/library/ms182244(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="IdentifiersShouldNotHaveIncorrectSuffix">
<name><![CDATA[Identifiers should not have incorrect suffix]]></name>
<configKey><![CDATA[IdentifiersShouldNotHaveIncorrectSuffix@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Types that do not extend certain base types should not use reserved name suffixes. Types and members should not use 'Ex' or 'New' to distinguish them from an earlier version of the same API, instead, use a numeric suffix such as '2' or provide a more meaningful suffix. Concrete type implementations and members should not end 'Impl'. Members instead, should either consider using the suggested alternate 'Core' in replacement of 'Impl' or avoid any suffix at all.<br/>
<a href="http://msdn.microsoft.com/library/ms182247(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotPrefixEnumValuesWithTypeName">
<name><![CDATA[Do not prefix enum values with type name]]></name>
<configKey><![CDATA[DoNotPrefixEnumValuesWithTypeName@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[The individual values that make up an enumeration type should not be prefixed with the type name.<br/>
<a href="http://msdn.microsoft.com/library/ms182237(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="EventsShouldNotHaveBeforeOrAfterPrefix">
<name><![CDATA[Events should not have before or after prefix]]></name>
<configKey><![CDATA[EventsShouldNotHaveBeforeOrAfterPrefix@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Use present and past tense for pre-events and post-events, instead of using 'Before' and 'After'. For example, use Closing and Closed rather than BeforeClose and AfterClose.<br/>
<a href="http://msdn.microsoft.com/library/ms182238(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="FlagsEnumsShouldHavePluralNames">
<name><![CDATA[Flags enums should have plural names]]></name>
<configKey><![CDATA[FlagsEnumsShouldHavePluralNames@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[An enumeration marked with FlagsAttribute should have a plural name.<br/>
<a href="http://msdn.microsoft.com/library/bb264486(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="IdentifiersShouldHaveCorrectPrefix">
<name><![CDATA[Identifiers should have correct prefix]]></name>
<configKey><![CDATA[IdentifiersShouldHaveCorrectPrefix@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Prefix interface names with the letter 'I' to indicate that the type is an interface, as in IFormattable. Prefix generic type parameter names with the letter 'T' and provide them with descriptive names, as in Dictionary<TKey, TValue>, unless a single 'T' is completely self-explanatory, as in Collection<T>. Use Pascal casing for both interface and type parameter names. Use abbreviations sparingly. Do not use the underscore character. Do use similar names when defining a class/interface pair where the class is a standard implementation of the interface. The names should differ only by the letter I prefixed on the interface name, as with Component and IComponent.<br/>
<a href="http://msdn.microsoft.com/library/ms182243(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="IdentifiersShouldNotMatchKeywords">
<name><![CDATA[Identifiers should not match keywords]]></name>
<configKey><![CDATA[IdentifiersShouldNotMatchKeywords@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Identifiers which conflict with reserved language keywords should be avoided. Using a reserved keyword as an identifier makes it harder for consumers in other languages to use your API.<br/>
<a href="http://msdn.microsoft.com/library/ms182248(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="OnlyFlagsEnumsShouldHavePluralNames">
<name><![CDATA[Only FlagsAttribute enums should have plural names]]></name>
<configKey><![CDATA[OnlyFlagsEnumsShouldHavePluralNames@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Plural names indicate that the values of the enumeration can be combined. For example, an enumeration named 'Day' indicates a single day, and an enumeration named 'Days' indicates multiple days. Enumeration values should be combined using the bit-wise OR operator only if the Flags attribute is present on the enumeration.<br/>
<a href="http://msdn.microsoft.com/library/bb264487(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ParameterNamesShouldNotMatchMemberNames">
<name><![CDATA[Parameter names should not match member names]]></name>
<configKey><![CDATA[ParameterNamesShouldNotMatchMemberNames@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Parameter names should be distinct from member names.<br/>
<a href="http://msdn.microsoft.com/library/ms182252(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="IdentifiersShouldNotContainTypeNames">
<name><![CDATA[Identifiers should not contain type names]]></name>
<configKey><![CDATA[IdentifiersShouldNotContainTypeNames@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Avoid using language-specific types name in parameters and members and data type identifiers in parameters. Types names might not be intuitive for all developers. It is recommended that you select a generic name, such as 'value', instead. If this is not sufficient, be sure to use the type name as it is defined in the .NET Framework Library and avoid language-specific type names completely. Some examples of C#-specific type names are 'float' (use 'Single' if a generic name is not sufficient), and 'ulong' (use 'UInt64' if a generic name is not sufficient).<br/>
<a href="http://msdn.microsoft.com/library/bb531486(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="PropertyNamesShouldNotMatchGetMethods">
<name><![CDATA[Property names should not match get methods]]></name>
<configKey><![CDATA[PropertyNamesShouldNotMatchGetMethods@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[A Get method was found with the same name as a property. Get methods and properties should have names that clearly distinguish their function. See the design guidelines for information regarding choosing properties over methods.<br/>
<a href="http://msdn.microsoft.com/library/ms182253(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="IdentifiersShouldNotHaveIncorrectPrefix">
<name><![CDATA[Identifiers should not have incorrect prefix]]></name>
<configKey><![CDATA[IdentifiersShouldNotHaveIncorrectPrefix@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Do not use 'C' as a prefix for type names. Do not use any prefix for naming types. Consider using the name of the base class as the suffix when naming derived types. For example: ApplicationException is a kind of Exception. SerializableAttribute is a kind of Attribute.<br/>
<a href="http://msdn.microsoft.com/library/ms182246(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TypeNamesShouldNotMatchNamespaces">
<name><![CDATA[Type names should not match namespaces]]></name>
<configKey><![CDATA[TypeNamesShouldNotMatchNamespaces@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Identifiers which conflict in whole or in part with namespace names should be avoided. Names that describe the purpose or contents of a type are preferred.<br/>
<a href="http://msdn.microsoft.com/library/ms182257(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ParameterNamesShouldMatchBaseDeclaration">
<name><![CDATA[Parameter names should match base declaration]]></name>
<configKey><![CDATA[ParameterNamesShouldMatchBaseDeclaration@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[For usability reasons, parameter names in overridden methods should match those of the base declaration.<br/>
<a href="http://msdn.microsoft.com/library/ms182251(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="UsePreferredTerms">
<name><![CDATA[Use preferred terms]]></name>
<configKey><![CDATA[UsePreferredTerms@$(FxCopDir)\Rules\NamingRules.dll
]]></configKey>
<category name="Maintainability" />
<description><![CDATA[Use preferred terms over deprecated alternates.<br/>
<a href="http://msdn.microsoft.com/library/ms182258(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotCastUnnecessarily">
<name><![CDATA[Do not cast unnecessarily]]></name>
<configKey><![CDATA[DoNotCastUnnecessarily@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[Avoid duplicate casts where possible, since there is a cost associated with them.<br/>
<a href="http://msdn.microsoft.com/library/ms182271(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="UseLiteralsWhereAppropriate">
<name><![CDATA[Use literals where appropriate]]></name>
<configKey><![CDATA[UseLiteralsWhereAppropriate@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[Prefer literals over InitOnly fields if values do not have to be calculated at runtime.<br/>
<a href="http://msdn.microsoft.com/library/ms182280(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="RemoveUnusedLocals">
<name><![CDATA[Remove unused locals (FxCop10)]]></name>
<configKey><![CDATA[RemoveUnusedLocals@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[Remove locals that are not used or are only assigned to in method implementations.<br/>
<a href="http://msdn.microsoft.com/library/ms182278(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AvoidExcessiveLocals">
<name><![CDATA[Avoid excessive locals]]></name>
<configKey><![CDATA[AvoidExcessiveLocals@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[Method implementations should not contain more than 64 local variables. In order for the run-time to enregister local variables most efficiently, there should be 64 or fewer of them. Enregistering based on flow analysis will not occur for locals in excess of 64, which may result in slower performance.<br/>
<a href="http://msdn.microsoft.com/library/ms182263(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="InitializeReferenceTypeStaticFieldsInline">
<name><![CDATA[Initialize reference type static fields inline]]></name>
<configKey><![CDATA[InitializeReferenceTypeStaticFieldsInline@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[Static fields should be initialized when declared. Initializing static data in explicit static constructors results in less performant code.<br/>
<a href="http://msdn.microsoft.com/library/ms182275(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AvoidUncalledPrivateCode">
<name><![CDATA[Avoid uncalled private code (FxCop10)]]></name>
<configKey><![CDATA[AvoidUncalledPrivateCode@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[There is uncalled code that is not externally visible and is not a known runtime entry point. If this violation fires in error, please send a problem report to the Visual Studio Code Analysis team.<br/>
<a href="http://msdn.microsoft.com/library/ms182264(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AvoidUninstantiatedInternalClasses">
<name><![CDATA[Avoid uninstantiated internal classes (FxCop10)]]></name>
<configKey><![CDATA[AvoidUninstantiatedInternalClasses@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[An internal class was detected that is apparently never instantiated. This rule does not attempt to detect late-bound creation and will generate false positives if instances of a type are only created in this way (for example, by means of Activator.CreateInstance or by passing the type as an argument to a TypeConverter constructor).<br/>
<a href="http://msdn.microsoft.com/library/ms182265(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AvoidUnsealedAttributes">
<name><![CDATA[Avoid unsealed attributes (FxCop10)]]></name>
<configKey><![CDATA[AvoidUnsealedAttributes@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[Seal attribute types for improved performance. Sealing attribute types speeds up performance during reflection on custom attributes.<br/>
<a href="http://msdn.microsoft.com/library/ms182267(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="PreferJaggedArraysOverMultidimensional">
<name><![CDATA[Prefer jagged arrays over multidimensional (FxCop10)]]></name>
<configKey><![CDATA[PreferJaggedArraysOverMultidimensional@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[Multidimensional arrays can have a negative impact on performance. Use a jagged array if possible.<br/>
<a href="http://msdn.microsoft.com/library/ms182277(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="OverrideEqualsAndOperatorEqualsOnValueTypes">
<name><![CDATA[Override equals and operator equals on value types]]></name>
<configKey><![CDATA[OverrideEqualsAndOperatorEqualsOnValueTypes@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[The default System.ValueType implementation might not perform as well as a custom implementation.<br/>
<a href="http://msdn.microsoft.com/library/ms182276(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="PropertiesShouldNotReturnArrays">
<name><![CDATA[Properties should not return arrays (FxCop10)]]></name>
<configKey><![CDATA[PropertiesShouldNotReturnArrays@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[Properties that return arrays are prone to code inefficiencies. Consider using a collection or making this a method. See the design guidelines for more information.<br/>
<a href="http://msdn.microsoft.com/library/0fss9skc(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TestForEmptyStringsUsingStringLength">
<name><![CDATA[Test for empty strings using string length]]></name>
<configKey><![CDATA[TestForEmptyStringsUsingStringLength@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[To test for empty strings, check if String.Length is equal to zero. Constructs such as "".Equals(someString) and String.Empty.Equals(someString) are less efficient than testing the string length. Replace these with checks for someString.Length == 0.<br/>
<a href="http://msdn.microsoft.com/library/ms182279(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="RemoveEmptyFinalizers">
<name><![CDATA[Remove empty finalizers]]></name>
<configKey><![CDATA[RemoveEmptyFinalizers@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[Finalizers should be avoided where possible, to avoid the additional performance overhead involved in tracking object lifetime.<br/>
<a href="http://msdn.microsoft.com/library/bb264476(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MarkMembersAsStatic">
<name><![CDATA[Mark members as static (FxCop10)]]></name>
<configKey><![CDATA[MarkMembersAsStatic@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[Methods which do not access instance data or call instance methods can be marked as static (Shared in Visual Basic). After doing so, the compiler will emit non-virtual call sites to these members which will prevent a check at runtime for each call that ensures the current object pointer is non-null. This can result in a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue.<br/>
<a href="http://msdn.microsoft.com/library/ms245046(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AvoidUnusedPrivateFields">
<name><![CDATA[Avoid unused private fields (FxCop10)]]></name>
<configKey><![CDATA[AvoidUnusedPrivateFields@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[Private fields were detected that do not appear to be accessed within the assembly. If this violation fires in error, please send a problem report to the Visual Studio Code Analysis team.<br/>
<a href="http://msdn.microsoft.com/library/ms245042(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MarkAssembliesWithNeutralResourcesLanguage">
<name><![CDATA[Mark assemblies with NeutralResourcesLanguageAttribute (FxCop10)
]]></name>
<configKey><![CDATA[MarkAssembliesWithNeutralResourcesLanguage@$(FxCopDir)\Rules\PerformanceRules.dll
]]></configKey>
<category name="Efficiency" />
<description><![CDATA[The NeutralResourcesLanguage attribute informs the ResourceManager of the language used to render the neutral culture's resources for an assembly. When looking up resources in the same culture as the neutral resources language, the ResourceManager automatically uses the resources located in the main assembly, instead of searching for a satellite assembly with the current user interface culture for the current thread. This will improve lookup performance for the first resource you load and can reduce your working set.<br/>
<a href="http://msdn.microsoft.com/library/bb385967(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ValueTypeFieldsShouldBePortable">
<name><![CDATA[Value type fields should be portable (FxCop10)]]></name>
<configKey><![CDATA[ValueTypeFieldsShouldBePortable@$(FxCopDir)\Rules\PortabilityRules.dll
]]></configKey>
<category name="Portability" />
<description><![CDATA[Structures with explicit layout containing misaligned fields cause crashes on 64-bit platforms.<br/>
<a href="http://msdn.microsoft.com/library/ms182285(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="PInvokeDeclarationsShouldBePortable">
<name><![CDATA[P/Invoke declarations should be portable (FxCop10)]]></name>
<configKey><![CDATA[PInvokeDeclarationsShouldBePortable@$(FxCopDir)\Rules\PortabilityRules.dll
]]></configKey>
<category name="Portability" />
<description><![CDATA[.<br/>
<a href="http://msdn.microsoft.com/library/ms182284(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="UseOnlyApiFromTargetedFramework">
<name><![CDATA[Use only API from targeted framework (FxCop10)]]></name>
<configKey><![CDATA[UseOnlyApiFromTargetedFramework@$(FxCopDir)\Rules\PortabilityRules.dll
]]></configKey>
<category name="Portability" />
<description><![CDATA[
<br/>
<a href="http://msdn.microsoft.com/library/cc667408(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="CatchNonClsCompliantExceptionsInGeneralHandlers">
<name><![CDATA[Catch non-CLSCompliant exceptions in general handlers (FxCop10)
]]></name>
<configKey><![CDATA[CatchNonClsCompliantExceptionsInGeneralHandlers@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Exception handlers which are truly intended to catch all exceptions should handle non-CLSCompliant exceptions if there is a possibility one can be raised. If possible, catch handlers should only catch specific exceptions or exception base types. In circumstances where a handler is required to catch all exceptions (e.g., when a try block wraps arbitrary plug-in code), the handler should also include a generic catch handler (in C#, catch{ ... }) to handle non-CLSCompliant exceptions. It is possible to raise non-CLSCompliant exceptions by modifying and recompiling IL.<br/>
<a href="http://msdn.microsoft.com/library/bb264489(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ReviewImperativeSecurity">
<name><![CDATA[Review imperative security (FxCop10)]]></name>
<configKey><![CDATA[ReviewImperativeSecurity@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Use of imperative demands can lead to unforeseen security problems. The values used to construct a permission should not change within the scope of the demand call. For some components the scope spans from the demand call to end of the method; for others it spans from the demand call until the component is finalized. If the values used to construct the permission are fields or properties, they can be changed within the scope of the demand call. This can lead to race conditions, mutable read-only arrays, and problems with boxed value types.<br/>
<a href="http://msdn.microsoft.com/library/ms182309(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotDeclareReadOnlyMutableReferenceTypes">
<name><![CDATA[Do not declare read only mutable reference types (FxCop10)
]]></name>
<configKey><![CDATA[DoNotDeclareReadOnlyMutableReferenceTypes@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[A read-only declaration for a mutable reference type does not prevent the field's instance data from being modified. For example, a read-only StringBuilder field declaration does not make sense, since the data encapsulated by the StringBuilder can be modified using the read-only reference.<br/>
<a href="http://msdn.microsoft.com/library/ms182302(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ArrayFieldsShouldNotBeReadOnly">
<name><![CDATA[Array fields should not be read only (FxCop10)]]></name>
<configKey><![CDATA[ArrayFieldsShouldNotBeReadOnly@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Read-only fields that reference arrays might not give the intended effect. Setting a field which references an array to read-only prevents the value of the field from being changed. Note that elements in the array can be changed. You can ignore this violation if protecting the contents of the array is not a concern.<br/>
<a href="http://msdn.microsoft.com/library/ms182299(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="SecureAsserts">
<name><![CDATA[Secure asserts (FxCop10)]]></name>
<configKey><![CDATA[SecureAsserts@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Asserting a security permission without performing any security checks can leave an exploitable security weakness in your code. A security stack walk stops when a security permission is asserted. If you assert a permission without performing any checks on the caller, the caller might be able to indirectly execute code using your permissions. Asserts without security checks are only permissible when you are certain that the assert cannot be used in a harmful fashion, namely, if the code you call is harmless, or users have no way to pass arbitrary information to code that you call.<br/>
<a href="http://msdn.microsoft.com/library/ms182314(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ReviewDenyAndPermitOnlyUsage">
<name><![CDATA[Review deny and permit only usage (FxCop10)]]></name>
<configKey><![CDATA[ReviewDenyAndPermitOnlyUsage@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Use of Deny or PermitOnly should be carefully reviewed. Use of Deny or PermitOnly should be carefully considered, as they are not useful in some cases. For example, permissions that are path-based (like FileIOPermission and RegistryPermission) should not be used with Deny, because different paths might actually point to the same location. If callers are granted the right to assert permissions by the security policy, then they can terminate a stack walk before it reaches your Deny or PermitOnly. If a caller has been granted powerful permissions (such as the ability to call unmanaged code), then calling Deny or PermitOnly cannot truly stop it from doing whatever it chooses. Also consider that Deny and PermitOnly do not affect a LinkDemand. For instance, if you deny some permission P and call a method with a LinkDemand for P, the Deny will not affect the result of the LinkDemand.<br/>
<a href="http://msdn.microsoft.com/library/ms182308(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ReviewDeclarativeSecurityOnValueTypes">
<name><![CDATA[Review declarative security on value types (FxCop10)]]></name>
<configKey><![CDATA[ReviewDeclarativeSecurityOnValueTypes@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[A Demand or a LinkDemand on a structure does not prevent creation of an instance of that structure.<br/>
<a href="http://msdn.microsoft.com/library/ms182307(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ReviewVisibleEventHandlers">
<name><![CDATA[Review visible event handlers (FxCop10)]]></name>
<configKey><![CDATA[ReviewVisibleEventHandlers@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[It appears that an event handler is externally visible or that an EventArgs parameter is being exposed in a visible method decorated with a security demand. There can be problems exposing sensitive functionality in an event handler function; the security demand might not do what you expect.<br/>
<a href="http://msdn.microsoft.com/library/ms182312(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="PointersShouldNotBeVisible">
<name><![CDATA[Pointers should not be visible (FxCop10)]]></name>
<configKey><![CDATA[PointersShouldNotBeVisible@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[IntPtr and UIntPtr fields should be declared as private. Exposing non-private pointers can cause a security weakness.<br/>
<a href="http://msdn.microsoft.com/library/ms182306(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="SecuredTypesShouldNotExposeFields">
<name><![CDATA[Secured types should not expose fields (FxCop10)]]></name>
<configKey><![CDATA[SecuredTypesShouldNotExposeFields@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Fields must be secured with a security check other than LinkDemand.<br/>
<a href="http://msdn.microsoft.com/library/ms182318(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MethodSecurityShouldBeASupersetOfType">
<name><![CDATA[Method security should be a superset of type (FxCop10)]]></name>
<configKey><![CDATA[MethodSecurityShouldBeASupersetOfType@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[A method has security set at both the type and method levels. This might not have the intended effect. Security actions on the type level are overridden by security actions on the method level. When employing both type-level and method-level security, type-level security actions that are not also on the method will be ignored when the method executes.<br/>
<a href="http://msdn.microsoft.com/library/ms182304(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="CallGCKeepAliveWhenUsingNativeResources">
<name><![CDATA[Call GC.KeepAlive when using native resources (FxCop10)]]></name>
<configKey><![CDATA[CallGCKeepAliveWhenUsingNativeResources@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[If a method uses an IntPtr or UIntPtr field in a class with a finalizer and does not call GC.KeepAlive, a race condition might be introduced.<br/>
<a href="http://msdn.microsoft.com/library/ms182300(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AptcaMethodsShouldOnlyCallAptcaMethods">
<name><![CDATA[APTCA methods should only call APTCA methods (FxCop10)]]></name>
<configKey><![CDATA[AptcaMethodsShouldOnlyCallAptcaMethods@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Methods with the AllowPartiallyTrustedCallersAttribute that call methods without that attribute might unintentionally expose functionality to partially trusted code. When a method has the AllowPartiallyTrustedCallersAttribute set, it is callable by partially trusted code. If it in turn calls methods without the attribute, a partially trusted caller is, in effect, being allowed to execute code that requires full trust. Depending on what full trust code is called and what parameter values are passed through from the partially trusted caller, malicious code might be able to exploit this security weakness.<br/>
<a href="http://msdn.microsoft.com/library/ms182297(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AptcaTypesShouldOnlyExtendAptcaBaseTypes">
<name><![CDATA[APTCA types should only extend APTCA base types (FxCop10)]]></name>
<configKey><![CDATA[AptcaTypesShouldOnlyExtendAptcaBaseTypes@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Types with the AllowPartiallyTrustedCallersAttribute that extend types without that attribute might unintentionally expose functionality in the base type to partially trusted callers. When a type has the AllowPartiallyTrustedCallersAttribute set, it is callable by partially trusted code. If the base type does not have this attribute, it requires callers to be fully trusted. If the derived type exposes protected members in the base type, the base type's data is made accessible to partially trusted callers, creating an exploitable security weakness.<br/>
<a href="http://msdn.microsoft.com/library/ms182298(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ReviewSuppressUnmanagedCodeSecurityUsage">
<name><![CDATA[Review SuppressUnmanagedCodeSecurityAttribute usage (FxCop10)
]]></name>
<configKey><![CDATA[ReviewSuppressUnmanagedCodeSecurityUsage@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Calling a method with the SuppressUnmanagedCodeSecurityAttribute applied to it can create a security weakness. Unmanaged code security checks ensure that all callers in the call stack have permission to execute unmanaged code. Disabling code security for P/Invoke methods allows callers that do not have this permission to breach security. This is acceptable only if the code is completely harmless, or callers have no way to pass arbitrary arguments through to the unmanaged code.<br/>
<a href="http://msdn.microsoft.com/library/ms182311(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="SealMethodsThatSatisfyPrivateInterfaces">
<name><![CDATA[Seal methods that satisfy private interfaces (FxCop10)]]></name>
<configKey><![CDATA[SealMethodsThatSatisfyPrivateInterfaces@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Externally visible types that implement non-public interfaces should not be extensible. Types that extend public types with non-public interfaces can override interface members. This can compromise object behavior or create a security vulnerability.<br/>
<a href="http://msdn.microsoft.com/library/ms182313(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="SecureSerializationConstructors">
<name><![CDATA[Secure serialization constructors (FxCop10)]]></name>
<configKey><![CDATA[SecureSerializationConstructors@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Serializable types that have a constructor protected by a security demand must apply the same security demands to the serialization constructor. Apply the demand using declarative security.<br/>
<a href="http://msdn.microsoft.com/library/ms182317(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="StaticConstructorsShouldBePrivate">
<name><![CDATA[Static constructors should be private (FxCop10)]]></name>
<configKey><![CDATA[StaticConstructorsShouldBePrivate@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Non-private static constructors can cause unexpected behaviors, particularly when executed multiple times. This violation can occur if a type declares static data but has not explicitly declared a static constructor. In this case, some compilers will generate an externally visible static constructor.<br/>
<a href="http://msdn.microsoft.com/library/ms182320(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotIndirectlyExposeMethodsWithLinkDemands">
<name><![CDATA[Do not indirectly expose methods with link demands (FxCop10)
]]></name>
<configKey><![CDATA[DoNotIndirectlyExposeMethodsWithLinkDemands@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Do not wrap a method protected by a LinkDemand with a method that does not perform a security check. A LinkDemand checks the permissions of the immediate caller rather than checking the permissions of all callers in the call stack. In this case, the permissions of the wrapper method will be checked. If the wrapper method does not, itself, check the permissions of callers higher in the call stack, malicious code might be able to execute the wrapped function even though it lacks permission to do so.<br/>
<a href="http://msdn.microsoft.com/library/ms182303(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="WrapVulnerableFinallyClausesInOuterTry">
<name><![CDATA[Wrap vulnerable finally clauses in outer try (FxCop10)]]></name>
<configKey><![CDATA[WrapVulnerableFinallyClausesInOuterTry@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Finally clauses that restore security-related state should be wrapped in an outer try block. This will prevent an exception filter further up the stack from executing before a secure environment can be restored. Exception filters that run code expressions in the first pass after the guarded try blocks and before the associated finally block represent a possible security vulnerability. Examples of vulnerable functionality in finally clauses that should be protected against this include: calls to RevertAssert on an asserted permission, undoing a temporary impersonation, reversing an internal flag that bypasses a security check, and restoring the culture associated with a thread.<br/>
<a href="http://msdn.microsoft.com/library/ms182322(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TypeLinkDemandsRequireInheritanceDemands">
<name><![CDATA[Type link demands require inheritance demands (FxCop10)]]></name>
<configKey><![CDATA[TypeLinkDemandsRequireInheritanceDemands@$(FxCopDir)\Rules\SecurityRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Unsealed types secured by a LinkDemand should also specify an InheritanceDemand. Without an InheritanceDemand, the link demand can be circumvented by overriding a method in a derived class.<br/>
<a href="http://msdn.microsoft.com/library/ms182321(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ConstantsShouldBeTransparent">
<name><![CDATA[Security critical constants should be transparent (FxCop10)
]]></name>
<configKey><![CDATA[ConstantsShouldBeTransparent@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Compilers inline accesses to constants, and as such transparency enforcement is not done for them since there is no runtime access to the field. These fields should be security transparent so that code reviewers do not assume that transparent code cannot access the constant.<br/>
<a href="http://msdn.microsoft.com/library/dd997446(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="CriticalTypesMustNotParticipateInTypeEquivalence">
<name><![CDATA[Security critical types may not participate in type equivalence
(FxCop10)]]></name>
<configKey><![CDATA[CriticalTypesMustNotParticipateInTypeEquivalence@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Type equivalence requires that all participating types, as well as all methods and fields within those types, are transparent or security safe-critical. The CLR will fail to load any type which violates this rule.<br/>
<a href="http://msdn.microsoft.com/library/dd997564(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DefaultConstructorsMustHaveConsistentTransparency">
<name><![CDATA[Default constructors must be at least as critical as base type
default constructors (FxCop10)]]></name>
<configKey><![CDATA[DefaultConstructorsMustHaveConsistentTransparency@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[On CoreCLR, if a base type has a public or protected non-transparent default constructor than the derived type must obey default constructor inheritance rules. The derived type must also have a default constructor and that constructor must be at least as critical as the base type’s default constructor. If the base type’s default constructor is safe-critical, the derived type’s default constructor must be safe-critical or critical. If the base type’s default constructor is critical, then the derived type’s default constructor must also be critical.<br/>
<a href="http://msdn.microsoft.com/library/dd983956(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DelegatesMustBindWithConsistentTransparency">
<name><![CDATA[Delegates must bind to methods with consistent transparency
(FxCop10)]]></name>
<configKey><![CDATA[DelegatesMustBindWithConsistentTransparency@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Delegate types and the methods that they bind to must have consistent transparency. Transparent and safe-critical delegates may only bind to other transparent or safe-critical methods. Similarly, critical delegates may only bind to critical methods. These binding rules ensure that the only code which can invoke a method via a delegate could have also invoked the same method directly. It prevents, for instance, transparent code from calling critical code directly via a transparent delegate.<br/>
<a href="http://msdn.microsoft.com/library/dd997710(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MethodsMustOverrideWithConsistentTransparency">
<name><![CDATA[Methods must keep consistent transparency when overriding base
methods (FxCop10)]]></name>
<configKey><![CDATA[MethodsMustOverrideWithConsistentTransparency@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Transparency visibility must be preserved between overriding methods and the methods that are being overridden. If the virtual method being overridden or interface method being implemented is security safe-critical or security transparent, then the overriding method must also be either security safe-critical or security transparent. Similarly, if the method being overridden is security critical, the overriding method must be security critical.<br/>
<a href="http://msdn.microsoft.com/library/dd997447(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="OverrideLinkDemandsShouldBeIdenticalToBase">
<name><![CDATA[Override link demands should be identical to base (FxCop10)
]]></name>
<configKey><![CDATA[OverrideLinkDemandsShouldBeIdenticalToBase@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[If a virtual method has a LinkDemand, in many cases, so should any override of it, and if an override has a LinkDemand, so should the overridden virtual method. Because it is possible to call any of the overrides of a virtual method explicitly, they should all have the same LinkDemand status or, if not, should be reviewed. This also applies to LinkDemand security checks for methods that part of an interface implementation, because the caller might use an interface-typed reference to access the method.<br/>
<a href="http://msdn.microsoft.com/library/ms182305(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="SecurityRuleSetLevel2MethodsShouldNotBeProtectedWithLinkDemands">
<name><![CDATA[Level 2 assemblies should not contain LinkDemands (FxCop10)
]]></name>
<configKey><![CDATA[SecurityRuleSetLevel2MethodsShouldNotBeProtectedWithLinkDemands@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[LinkDemands are deprecated in the level 2 security rule set. Instead of using LinkDemands to enforce JIT time security, SecurityCritical methods, types, and fields should be used instead.<br/>
<a href="http://msdn.microsoft.com/library/dd997569(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TransparencyAnnotationsShouldNotConflict">
<name><![CDATA[Members should not have conflicting transparency annotations
(FxCop10)]]></name>
<configKey><![CDATA[TransparencyAnnotationsShouldNotConflict@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Transparency attributes are applied from larger scopes inward. For instance, if a type is marked as entirely security critical, than all methods introduced by the type will also be security critical. Members should not have transparency annotations which conflict with larger scoped annotations, as these smaller scoped annotations will be ignored by the CLR and can be misleading during a code review. Methods not introduced by their type, such as virtual methods being overridden from a base type or interface methods being implemented, do have their annotations considered under the level 2 security rule set and are not considered by this rule.<br/>
<a href="http://msdn.microsoft.com/library/bb264493(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TransparentCodeMustNotUseCriticalAttributes">
<name><![CDATA[Transparent code may not use security critical attributes
(FxCop10)]]></name>
<configKey><![CDATA[TransparentCodeMustNotUseCriticalAttributes@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Transparent code must not use security critical attributes. This includes using security critical constructors, properties, or fields of attributes. Violations of this rule will result in an exception when code attempts to retrieve the custom attributes from the transparent target.<br/>
<a href="http://msdn.microsoft.com/library/">msdn help page</a>
]]></description>
</rule>
<rule key="TransparentMethodsMustBeVerifiable">
<name><![CDATA[Transparent methods must contain only verifiable IL (FxCop10)
]]></name>
<configKey><![CDATA[TransparentMethodsMustBeVerifiable@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Transparent code must be fully verifiable. This rule looks for any use of pointer types to check for unverifiable code, however it is not a complete verifier and PEVerify / transparent must be run on assemblies to ensure that all of their transparent code is verifiable.<br/>
<a href="http://msdn.microsoft.com/library/dd983954(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TransparentMethodsMustNotCallNativeCode">
<name><![CDATA[Transparent methods must not call into native code (FxCop10)
]]></name>
<configKey><![CDATA[TransparentMethodsMustNotCallNativeCode@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Transparent code may not call native code directly. This rule looks for any transparent code which calls a method stub (such as a P/Invoke declaration) which is really a direct call into native code.<br/>
<a href="http://msdn.microsoft.com/library/ee155709(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule
key="TransparentMethodsMustNotCallSuppressUnmanagedCodeSecurityMethods">
<name><![CDATA[Transparent methods must not call methods with the
SuppressUnmanagedCodeSecurity attribute (FxCop10)]]></name>
<configKey><![CDATA[TransparentMethodsMustNotCallSuppressUnmanagedCodeSecurityMethods@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[P/Invoke and COM interop methods with the SuppressUnmanagedCodeSecurity attribute result in a LinkDemand being done against the calling method. Since security transparent code may not satisfy LinkDemands, it may also not call methods with SuppressUnmanagedCodeSecurity either on the method itself or on the type containing the method.<br/>
<a href="http://msdn.microsoft.com/library/dd997711(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TransparentMethodsMustNotHandleProcessCorruptingExceptions">
<name><![CDATA[Transparent methods may not use the
HandleProcessCorruptingExceptions attribute (FxCop10)]]></name>
<configKey><![CDATA[TransparentMethodsMustNotHandleProcessCorruptingExceptions@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[The HandleProcessCorruptingExceptions attribute may only be used by security critical methods, and will not be honored if it is applied to a transparent method.<br/>
<a href="http://msdn.microsoft.com/library/dd997565(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TransparentMethodsMustNotReferenceCriticalCode">
<name><![CDATA[Transparent code must not reference security critical items
(FxCop10)]]></name>
<configKey><![CDATA[TransparentMethodsMustNotReferenceCriticalCode@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Transparent code cannot refer to security critical methods, types, or fields. At runtime these references will result in MemberAccessExceptions or TypeLoadExceptions.<br/>
<a href="http://msdn.microsoft.com/library/bb264475(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TransparentMethodsMustNotSatisfyLinkDemands">
<name><![CDATA[Transparent methods must not satisfy LinkDemands (FxCop10)
]]></name>
<configKey><![CDATA[TransparentMethodsMustNotSatisfyLinkDemands@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Satisfying a LinkDemand is a security sensitive operation which can cause unintentional elevation of privilege. Security transparent code must not satisfy LinkDemands, since it is not subject to the same security audit requirements as security critical code. Transparent methods is security rule set level 1 assemblies will cause all LinkDemands they satisfy to be converted to full demands at runtime, which can cause performance problems. In security rule set level 2 assemblies, transparent methods will fail to JIT if they attempt to satisfy a LinkDemand.<br/>
<a href="http://msdn.microsoft.com/library/dd997445(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TransparentMethodsMustNotUseSecurityAsserts">
<name><![CDATA[Transparent code may not use security asserts (FxCop10)]]></name>
<configKey><![CDATA[TransparentMethodsMustNotUseSecurityAsserts@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Transparent code may not use security asserts, since asserting permissions can result in elevating the effective permissions of the call stack. Transparent code which attempts to assert will receive an InvalidOperationException at runtime.<br/>
<a href="http://msdn.microsoft.com/library/bb264482(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TransparentMethodsShouldNotBeProtectedWithLinkDemands">
<name><![CDATA[Transparent code should not be protected with LinkDemands
(FxCop10)]]></name>
<configKey><![CDATA[TransparentMethodsShouldNotBeProtectedWithLinkDemands@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Security transparent code should not be responsible for verifying the security of an operation, and therefore should not be protected from partial trust callers with LinkDemands.<br/>
<a href="http://msdn.microsoft.com/library/dd997567(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TransparentMethodsShouldNotDemand">
<name><![CDATA[Transparent methods should not use security demands (FxCop10)
]]></name>
<configKey><![CDATA[TransparentMethodsShouldNotDemand@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Security transparent code should not be responsible for verifying the security of an operation, and therefore should not demand permissions. Any code which is performing security checks, such as security demands, should be safe-critical instead.<br/>
<a href="http://msdn.microsoft.com/library/dd997566(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TransparentMethodsShouldNotLoadAssembliesFromByteArrays">
<name><![CDATA[Transparent code should not load assemblies from byte arrays
(FxCop10)]]></name>
<configKey><![CDATA[TransparentMethodsShouldNotLoadAssembliesFromByteArrays@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Assemblies loaded from byte arrays inherit the grant set of the loading assembly. Since this means that the loaded assembly may be fully trusted, any calls to load from byte array from trusted code should be reviewed to ensure that it is secure. Transparent code is not subjected to the same audit scrutiny as critical code, and therefore should not load assemblies from byte arrays.<br/>
<a href="http://msdn.microsoft.com/library/dd997568(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TransparentMethodsShouldNotUseSuppressUnmanagedCodeSecurity">
<name><![CDATA[Transparent methods should not be decorated with the
SuppressUnmanagedCodeSecurityAttribute (FxCop10)]]></name>
<configKey><![CDATA[TransparentMethodsShouldNotUseSuppressUnmanagedCodeSecurity@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[Methods decorated with the SuppressUnmanagedCodeSecurity attribute have an implicit LinkDemand placed upon all of their callers. This LinkDemand requires that the calling code be security critical. Marking the method which uses SuppressUnmanagedCodeSecurity as security critical makes this requirement more obvious for callers of the method.<br/>
<a href="http://msdn.microsoft.com/library/dd997570(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TypesMustBeAtLeastAsCriticalAsBaseTypes">
<name><![CDATA[Types must be at least as critical as their base types and
interfaces (FxCop10)]]></name>
<configKey><![CDATA[TypesMustBeAtLeastAsCriticalAsBaseTypes@$(FxCopDir)\Rules\SecurityTransparencyRules.dll
]]></configKey>
<category name="Reliability" />
<description><![CDATA[While any type may derive from a transparent type or interface, restrictions apply as to the types that can inherit from or implement safe-critical or critical types. Only safe-critical or critical types may derive from or implement safe-critical interfaces and base types. Only critical types may derive from or implement critical interfaces and base types.<br/>
<a href="http://msdn.microsoft.com/library/dd997443(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ReviewUnusedParameters">
<name><![CDATA[Review unused parameters (FxCop10)]]></name>
<configKey><![CDATA[ReviewUnusedParameters@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Review parameters in non-virtual methods that are not used in the method body to ensure no correctness exists around failure to access them. Unused parameters incur maintenance and performance costs. Sometimes a violation of this rule can point to an implementation bug in the method (i.e. the parameter should actually have been used in the method body). Exclude warnings of this rule if the parameter has to exist because of backward compatibility.<br/>
<a href="http://msdn.microsoft.com/library/ms182268(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotIgnoreMethodResults">
<name><![CDATA[Do not ignore method results (FxCop10)]]></name>
<configKey><![CDATA[DoNotIgnoreMethodResults@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[The result of methods that return new instances of strings should be assigned to a variable and subsequently used. If the result of a method that creates a new object, such as String.ToLower(), is not assigned to a variable, the call is wasted.<br/>
<a href="http://msdn.microsoft.com/library/ms182273(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="RethrowToPreserveStackDetails">
<name><![CDATA[Rethrow to preserve stack details (FxCop10)]]></name>
<configKey><![CDATA[RethrowToPreserveStackDetails@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Use the IL rethrow instruction to preserve original stack details when re-raising a caught exception.<br/>
<a href="http://msdn.microsoft.com/library/ms182363(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotRaiseReservedExceptionTypes">
<name><![CDATA[Do not raise reserved exception types (FxCop10)]]></name>
<configKey><![CDATA[DoNotRaiseReservedExceptionTypes@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[User code should not create and raise exceptions of certain types that are reserved by the runtime or which are of a too general exception type. Exception types that are too general include Exception, SystemException, and ApplicationException. Exception types that are reserved by the runtime include ThreadAbortException, OutOfMemoryException, ExecutionEngineException, and IndexOutOfRangeException.<br/>
<a href="http://msdn.microsoft.com/library/ms182338(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="UseManagedEquivalentsOfWin32Api">
<name><![CDATA[Use managed equivalents of Win32 API (FxCop10)]]></name>
<configKey><![CDATA[UseManagedEquivalentsOfWin32Api@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Use managed equivalents to Win32 API whenever possible.<br/>
<a href="http://msdn.microsoft.com/library/ms182365(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="InitializeValueTypeStaticFieldsInline">
<name><![CDATA[Initialize value type static fields inline (FxCop10)]]></name>
<configKey><![CDATA[InitializeValueTypeStaticFieldsInline@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Do not declare explicit static constructors on value types. Initializing static data in explicit static constructors results in a value type that is not marked in metadata as 'beforefieldinit'. In this case, the static constructor is not always guaranteed to be called before instance members on the value type are called.<br/>
<a href="http://msdn.microsoft.com/library/ms182346(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="InstantiateArgumentExceptionsCorrectly">
<name><![CDATA[Instantiate argument exceptions correctly (FxCop10)]]></name>
<configKey><![CDATA[InstantiateArgumentExceptionsCorrectly@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[String arguments passed to constructors of ArgumentException and its derived types should be correct. Types derived from ArgumentException have inconsistent constructor overloads with respect to the message and paramName parameters as compared to ArgumentException.<br/>
<a href="http://msdn.microsoft.com/library/ms182347(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="NonConstantFieldsShouldNotBeVisible">
<name><![CDATA[Non-constant fields should not be visible (FxCop10)]]></name>
<configKey><![CDATA[NonConstantFieldsShouldNotBeVisible@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Static fields should be constant unless you carefully manage access to the field using locks. Using static variables without making them thread safe can compromise execution state. This rule applies to managed code libraries. If the analyzed assembly is an application, it is usually safe to exclude violations of this rule.<br/>
<a href="http://msdn.microsoft.com/library/ms182353(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotMarkServicedComponentsWithWebMethod">
<name><![CDATA[Do not mark serviced components with WebMethod (FxCop10)]]></name>
<configKey><![CDATA[DoNotMarkServicedComponentsWithWebMethod@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Types that extend ServicedComponent should not have the WebMethod attribute applied to members. Marking members of types that extend ServicedComponent with WebMethod is not a supported scenario.<br/>
<a href="http://msdn.microsoft.com/library/ms182336(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DisposableFieldsShouldBeDisposed">
<name><![CDATA[Disposable fields should be disposed (FxCop10)]]></name>
<configKey><![CDATA[DisposableFieldsShouldBeDisposed@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[If a type that implements IDisposable owns fields that also implement IDisposable, the encapsulating type's Dispose() implementation should call Dispose() on each disposable field.<br/>
<a href="http://msdn.microsoft.com/library/ms182328(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotCallOverridableMethodsInConstructors">
<name><![CDATA[Do not call overridable methods in constructors (FxCop10)]]></name>
<configKey><![CDATA[DoNotCallOverridableMethodsInConstructors@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Virtual methods defined on the class should not be called from constructors. If a derived class has overridden the method, the derived class version will be called (before the derived class constructor is called).<br/>
<a href="http://msdn.microsoft.com/library/ms182331(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DisposableTypesShouldDeclareFinalizer">
<name><![CDATA[Disposable types should declare finalizer (FxCop10)]]></name>
<configKey><![CDATA[DisposableTypesShouldDeclareFinalizer@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[If a type implements a Dispose method and has unmanaged resources, it should provide a Finalize method in case Dispose is not explicitly called. The runtime calls the Finalize method or destructor of an object prior to reclaiming its managed resources in a process known as garbage collection. The Finalize method should free any unmanaged resources before they become inaccessible.<br/>
<a href="http://msdn.microsoft.com/library/ms182329(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotMarkEnumsWithFlags">
<name><![CDATA[Do not mark enums with FlagsAttribute (FxCop10)]]></name>
<configKey><![CDATA[DoNotMarkEnumsWithFlags@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[The enumeration does not appear to contain a consistent set values that can be combined using the OR (|) and AND (&amp;amp;) operators. Using the Flags attribute on an enumeration suggests that the enumeration values are meant to be combined using the AND and OR operators. Typically, a flags enumeration uses values that are either powers of two, or combine other values that are powers of two.<br/>
<a href="http://msdn.microsoft.com/library/ms182335(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="OverrideGetHashCodeOnOverridingEquals">
<name><![CDATA[Override GetHashCode on overriding Equals (FxCop10)]]></name>
<configKey><![CDATA[OverrideGetHashCodeOnOverridingEquals@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[When overriding Equals, you must also override GetHashCode to guarantee correct behavior with hashtables.<br/>
<a href="http://msdn.microsoft.com/library/ms182358(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotRaiseExceptionsInExceptionClauses">
<name><![CDATA[Do not raise exceptions in exception clauses (FxCop10)]]></name>
<configKey><![CDATA[DoNotRaiseExceptionsInExceptionClauses@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Raising exceptions in exception clauses greatly increases the difficulty of debugging. Exceptions raised in finally and fault clauses will hide any exceptions raised in the corresponding try block. If an exception is raised in a filter, it is ignored and treated as if the filter had returned false.<br/>
<a href="http://msdn.microsoft.com/library/bb386041(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="FinalizersShouldCallBaseClassFinalizer">
<name><![CDATA[Finalizers should call base class finalizer (FxCop10)]]></name>
<configKey><![CDATA[FinalizersShouldCallBaseClassFinalizer@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[The Finalize method should call its base class' Finalize method. This is done automatically with the C# destructor syntax.<br/>
<a href="http://msdn.microsoft.com/library/ms182341(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="FinalizersShouldBeProtected">
<name><![CDATA[Finalizers should be protected (FxCop10)]]></name>
<configKey><![CDATA[FinalizersShouldBeProtected@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Finalize methods should be declared as protected.<br/>
<a href="http://msdn.microsoft.com/library/ms182340(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotDecreaseInheritedMemberVisibility">
<name><![CDATA[Do not decrease inherited member visibility (FxCop10)]]></name>
<configKey><![CDATA[DoNotDecreaseInheritedMemberVisibility@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[It is incorrect to override a public method from an inherited class with a private implementation, unless the type is sealed or the method is marked final. It is considered bad form to hide a method signature halfway down an inheritance tree.<br/>
<a href="http://msdn.microsoft.com/library/ms182332(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MembersShouldDifferByMoreThanReturnType">
<name><![CDATA[Members should differ by more than return type (FxCop10)]]></name>
<configKey><![CDATA[MembersShouldDifferByMoreThanReturnType@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Methods in the same type that differ only by return type can be difficult for developers and tools to properly recognize. When extending a type, be sure not to define new methods that differ from base type methods only by type.<br/>
<a href="http://msdn.microsoft.com/library/ms182352(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="OverrideEqualsOnOverloadingOperatorEquals">
<name><![CDATA[Override Equals on overloading operator equals (FxCop10)]]></name>
<configKey><![CDATA[OverrideEqualsOnOverloadingOperatorEquals@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Types that redefine the equality operator should redefine Equals as well to ensure that these members return the same results. This helps ensure that types that rely on Equals (such as ArrayList and Hashtable) behave in a manner that is expected and consistent with the equality operator.<br/>
<a href="http://msdn.microsoft.com/library/ms182357(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="OperatorOverloadsHaveNamedAlternates">
<name><![CDATA[Operator overloads have named alternates (FxCop10)]]></name>
<configKey><![CDATA[OperatorOverloadsHaveNamedAlternates@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[When redefining operators, implement named methods to provide access to the operator functionality from languages that do not support operator overloading. For example, the functionality of the '+' operator should also be accessible using an 'Add' method.<br/>
<a href="http://msdn.microsoft.com/library/ms182355(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="OperatorsShouldHaveSymmetricalOverloads">
<name><![CDATA[Operators should have symmetrical overloads (FxCop10)]]></name>
<configKey><![CDATA[OperatorsShouldHaveSymmetricalOverloads@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Overload operators that have related meanings so that their behavior is consistent. For example, when overloading the equality operator, you should also overload the inequality operator to ensure they return opposite results for the same input values.<br/>
<a href="http://msdn.microsoft.com/library/ms182356(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="CollectionPropertiesShouldBeReadOnly">
<name><![CDATA[Collection properties should be read only (FxCop10)]]></name>
<configKey><![CDATA[CollectionPropertiesShouldBeReadOnly@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Properties that return collections should be read-only so that users cannot entirely replace the backing store. Users can still modify the contents of the collection by calling relevant methods on the collection. Note that the XmlSerializer class has special support for deserializing read-only collections. See the XmlSerializer overview for more information.<br/>
<a href="http://msdn.microsoft.com/library/ms182327(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="DoNotShipUnreleasedResourceFormats">
<name><![CDATA[Do not ship unreleased resource formats (FxCop10)]]></name>
<configKey><![CDATA[DoNotShipUnreleasedResourceFormats@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Resources generated by pre-release versions of the .NET Framework might contain incorrect or incomplete type references. Pre-release versions of the .NET Framework can generate partial or incomplete references to types. Resources built with pre-release software are not guaranteed to work correctly in released versions.<br/>
<a href="http://msdn.microsoft.com/library/ms182339(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ImplementSerializationConstructors">
<name><![CDATA[Implement serialization constructors (FxCop10)]]></name>
<configKey><![CDATA[ImplementSerializationConstructors@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[The constructor signature accepts the same arguments as ISerializable.GetObjectData, namely, a SerializationInfo instance and a StreamingContext instance. The constructor should be protected for non-sealed classes and private for sealed classes. Failure to implement a serialization constructor will cause deserialization to fail, and throw a SerializationException.<br/>
<a href="http://msdn.microsoft.com/library/ms182343(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="UseParamsForVariableArguments">
<name><![CDATA[Use params for variable arguments (FxCop10)]]></name>
<configKey><![CDATA[UseParamsForVariableArguments@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Do not use the varargs calling convention to accept a variable number of arguments. In the managed world, the 'params' and 'ParamArray' keywords provide this functionality..<br/>
<a href="http://msdn.microsoft.com/library/ms182366(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="OverloadOperatorEqualsOnOverridingValueTypeEquals">
<name><![CDATA[Overload operator equals on overriding ValueType.Equals
(FxCop10)]]></name>
<configKey><![CDATA[OverloadOperatorEqualsOnOverridingValueTypeEquals@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Value types that redefine System.ValueType.Equals should redefine the equality operator as well to ensure that these members return the same results. This helps ensure that types that rely on Equals (such as ArrayList and Hashtable) behave in a manner that is expected and consistent with the equality operator.<br/>
<a href="http://msdn.microsoft.com/library/ms182359(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MarkWindowsFormsEntryPointsWithStaThread">
<name><![CDATA[Mark Windows Forms entry points with STAThread (FxCop10)]]></name>
<configKey><![CDATA[MarkWindowsFormsEntryPointsWithStaThread@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Assemblies that reference System.Windows.Forms should have the STAThreadAttribute. Failure to apply this attribute will most likely result in an application that does not work. Windows Forms relies on a number of components that use the STA model.<br/>
<a href="http://msdn.microsoft.com/library/ms182351(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="OperationsShouldNotOverflow">
<name><![CDATA[Operations should not overflow (FxCop10)]]></name>
<configKey><![CDATA[OperationsShouldNotOverflow@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Arithmetic operations should not be done without first validating the operands to prevent overflow.<br/>
<a href="http://msdn.microsoft.com/library/ms182354(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="PassSystemUriObjectsInsteadOfStrings">
<name><![CDATA[Pass System.Uri objects instead of strings (FxCop10)]]></name>
<configKey><![CDATA[PassSystemUriObjectsInsteadOfStrings@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[If there are two overloads one taking System.Uri and one taking System.String, library code should never call the string-based overload.<br/>
<a href="http://msdn.microsoft.com/library/ms182360(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MarkAllNonSerializableFields">
<name><![CDATA[Mark all non-serializable fields (FxCop10)]]></name>
<configKey><![CDATA[MarkAllNonSerializableFields@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[All fields that cannot be serialized directly should have the NonSerializedAttribute. Types that have the SerializableAttribute should not have fields of types that do not have the SerializableAttribute unless the fields are marked with the NonSerializedAttribute.<br/>
<a href="http://msdn.microsoft.com/library/ms182349(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="CallBaseClassMethodsOnISerializableTypes">
<name><![CDATA[Call base class methods on ISerializable types (FxCop10)]]></name>
<configKey><![CDATA[CallBaseClassMethodsOnISerializableTypes@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Derived ISerializable types must call the base class magic constructor and the base class GetObjectData method.<br/>
<a href="http://msdn.microsoft.com/library/ms182326(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="MarkISerializableTypesWithSerializable">
<name><![CDATA[Mark ISerializable types with SerializableAttribute (FxCop10)
]]></name>
<configKey><![CDATA[MarkISerializableTypesWithSerializable@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[The System.Runtime.Serialization.ISerializable interface allows the type to customize its serialization, while the Serializable attribute enables the runtime to recognize the type as being serializable.<br/>
<a href="http://msdn.microsoft.com/library/ms182350(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ImplementSerializationMethodsCorrectly">
<name><![CDATA[Implement serialization methods correctly (FxCop10)]]></name>
<configKey><![CDATA[ImplementSerializationMethodsCorrectly@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Methods marked with OnSerializing, OnSerialized, OnDeserializing, or OnDeserialized, must be non-generic, private, return void (Sub in Visual Studio) and take a single parameter of type StreamingContext.<br/>
<a href="http://msdn.microsoft.com/library/ms182344(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ProvideDeserializationMethodsForOptionalFields">
<name><![CDATA[Provide deserialization methods for optional fields (FxCop10)
]]></name>
<configKey><![CDATA[ProvideDeserializationMethodsForOptionalFields@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[If a type contains fields attributed as OptionalField, then it should implement the corresponding special deserialization methods.<br/>
<a href="http://msdn.microsoft.com/library/ms182362(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="ImplementISerializableCorrectly">
<name><![CDATA[Implement ISerializable correctly (FxCop10)]]></name>
<configKey><![CDATA[ImplementISerializableCorrectly@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[If a type is assignable to ISerializable, it should implement GetObjectData. For unsealed types, the GetObjectData method should be callable and overridable by derived types.<br/>
<a href="http://msdn.microsoft.com/library/ms182342(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="TestForNaNCorrectly">
<name><![CDATA[Test for NaN correctly (FxCop10)]]></name>
<configKey><![CDATA[TestForNaNCorrectly@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Direct comparisons against 'Single.NaN' or 'Double.NaN' (not a number) always return true for inequality and false for all other comparisons; use 'Single.IsNaN' or 'Double.IsNaN' to check if a floating point value is NaN.<br/>
<a href="http://msdn.microsoft.com/library/bb264491(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="AttributeStringLiteralsShouldParseCorrectly">
<name><![CDATA[Attribute string literals should parse correctly (FxCop10)
]]></name>
<configKey><![CDATA[AttributeStringLiteralsShouldParseCorrectly@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Literal strings used as attribute parameters that represent URLs, version numbers, or GUIDs, should have the appropriate format.<br/>
<a href="http://msdn.microsoft.com/library/bb264490(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
<rule key="CallGCSuppressFinalizeCorrectly">
<name><![CDATA[Call GC.SuppressFinalize correctly (FxCop10)]]></name>
<configKey><![CDATA[CallGCSuppressFinalizeCorrectly@$(FxCopDir)\Rules\UsageRules.dll
]]></configKey>
<category name="Usability" />
<description><![CDATA[Call GC.SuppressFinalize to suppress finalization of your instance once Dispose has been called. Objects that implement IDisposable should call SuppressFinalize from the IDisposable.Dispose method to prevent the garbage collector from calling Object.Finalize on an object that does not require it.<br/>
<a href="http://msdn.microsoft.com/library/ms182269(VS.100).aspx">msdn help page</a>
]]></description>
</rule>
</rules>