• Home
• org.codehaus.sonar-plugins.dotnet.csharp
• sonar-csharp-gendarme-plugin
• 1.2
• source code
• rules.xml

×

Project download

Many resources are needed to download a project. Please understand that we have to compensate our server costs. Thank you in advance.
Project price only 1 $

You can buy this project and download/modify it how often you want.

org.sonar.plugins.csharp.gendarme.rules.rules.xml Maven / Gradle / Ivy

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<!--

    Sonar C# Plugin :: Gendarme
    Copyright (C) 2010 SonarSource, Jose Chillan and Alexandre Victoor

    Sonar is free software; you can redistribute it and/or
    modify it under the terms of the GNU Lesser General Public
    License as published by the Free Software Foundation; either
    version 3 of the License, or (at your option) any later version.

    Sonar is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
    Lesser General Public License for more details.

    You should have received a copy of the GNU Lesser General Public
    License along with Sonar; if not, write to the Free Software
    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02

-->

<rules>
	<rule key="AttributeStringLiteralsShouldParseCorrectlyRule">
		<name>AttributeStringLiteralsShouldParseCorrectlyRule</name>
		<configKey><![CDATA[AttributeStringLiteralsShouldParseCorrectlyRule@Gendarme.Rules.Correctness.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[As attributes are used at compile time, only constants can be passed to constructors. This can lead to runtime errors for things like malformed URI strings. This rule checks attributes with the following types, represented as a string, and validates the string value: <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#AttributeStringLiteralsShouldParseCorrectlyRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidConstructorsInStaticTypesRule">
		<name>AvoidConstructorsInStaticTypesRule</name>
		<configKey><![CDATA[AvoidConstructorsInStaticTypesRule@Gendarme.Rules.Correctness.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for types that contain only static members and fires if the type contains a visible instance constructor. This was a common mistake in the 1.x framework because C# adds a default, public, constructor if no other constructors are provided. Code using the framework 2.0 (and later) should change this type, if possible, into a static type. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#AvoidConstructorsInStaticTypesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidFloatingPointEqualityRule">
		<name>AvoidFloatingPointEqualityRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[In general floating point numbers cannot be usefully compared using the equality and inequality operators. This is because floating point numbers are inexact and most floating point operations introduce errors which can accumulate if multiple operations are performed. This rule will fire if [in]equality comparisons are used with <b>Single</b> or <b>Double</b> types. In general such comparisons should be done with some sort of epsilon test instead of a simple compare (see the code below). For more information: <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#AvoidFloatingPointEqualityRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="BadRecursiveInvocationRule">
		<name>BadRecursiveInvocationRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for a few common scenarios where a method may be infinitely recursive. For example, getter properties which call themselves or methods with no conditional code which call themselves (instead of the base method). <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#BadRecursiveInvocationRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="CallingEqualsWithNullArgRule">
		<name>CallingEqualsWithNullArgRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for methods that call <b>Equals</b> with a <b>null</b> actual parameter. Such calls should always return <b>false</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#CallingEqualsWithNullArgRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="CheckParametersNullityInVisibleMethodsRule">
		<name>CheckParametersNullityInVisibleMethodsRule</name>
		<configKey><![CDATA[CheckParametersNullityInVisibleMethodsRule@Gendarme.Rules.Correctness.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks if all nullable parameters of visible methods are compared with <b>null</b> before they get used. This reduce the likelyhood of the runtime throwing a <b>NullReferenceException</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#CheckParametersNullityInVisibleMethodsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DisposableFieldsShouldBeDisposedRule">
		<name>DisposableFieldsShouldBeDisposedRule</name>
		<configKey><![CDATA[DisposableFieldsShouldBeDisposedRule@Gendarme.Rules.Correctness.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[The rule inspects all fields for disposable types and, if <b>System.IDisposable</b> is implemented, checks that the type's <b>Dispose</b> method does indeed call <b>Dispose</b> on all disposable fields. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#DisposableFieldsShouldBeDisposedRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotCompareWithNaNRule">
		<name>DoNotCompareWithNaNRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[As defined in IEEE 754 it's impossible to compare any floating-point value, even another <b>NaN</b>, with <b>NaN</b>. Such comparison will always return <b>false</b>(more information on <a href="http://en.wikipedia.org/wiki/NaN" class="external" title="http://en.wikipedia.org/wiki/NaN" rel="nofollow">wikipedia</a><span class="urlexpansion">&amp;nbsp;(<i>http://en.wikipedia.org/wiki/NaN</i>)</span>). The framework provides methods, <b>Single.IsNaN</b> and <b>Double.IsNaN</b>, to check for <b>NaN</b> values. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#DoNotCompareWithNaNRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotRecurseInEqualityRule">
		<name>DoNotRecurseInEqualityRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[An operator== or operator!= method is calling itself recursively. This is usually caused by neglecting to cast an argument to System.Object before comparing it to null. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#DoNotRecurseInEqualityRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotRoundIntegersRule">
		<name>DoNotRoundIntegersRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule check for attempts to call <b>Round</b>, <b>Ceiling</b>, <b>Floor</b> or <b>Truncate</b> on an integral type. This often indicate a typo in the source code (e.g. wrong variable) or an unnecessary operation. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#DoNotRoundIntegersRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="EnsureLocalDisposalRule">
		<name>EnsureLocalDisposalRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks that disposable locals are always disposed of before the method returns. Use a 'using' statement (or a try/finally block) to guarantee local disposal even in the event an unhandled exception occurs. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#EnsureLocalDisposalRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="FinalizersShouldCallBaseClassFinalizerRule">
		<name>FinalizersShouldCallBaseClassFinalizerRule</name>
		<configKey><![CDATA[FinalizersShouldCallBaseClassFinalizerRule@Gendarme.Rules.Correctness.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule is used to warn the developer that a finalizer does not call the base class finalizer. In C#, this is enforced by compiler but some .NET languages (like IL) may allow such behavior. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#FinalizersShouldCallBaseClassFinalizerRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MethodCanBeMadeStaticRule">
		<name>MethodCanBeMadeStaticRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for methods that do not require anything from the current instance. Those methods can be converted into static methods, which helps a bit with performance (the hidden <b>this</b> parameter can be omitted), and clarifies the API. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#MethodCanBeMadeStaticRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ProvideCorrectArgumentsToFormattingMethodsRule">
		<name>ProvideCorrectArgumentsToFormattingMethodsRule</name>
		<configKey><![CDATA[ProvideCorrectArgumentsToFormattingMethodsRule@Gendarme.Rules.Correctness.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks that the format string used with <b>String.Format</b> matches the other parameters used with the method. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#ProvideCorrectArgumentsToFormattingMethodsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ProvideCorrectRegexPatternRule">
		<name>ProvideCorrectRegexPatternRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule verifies that valid regular expression strings are used as arguments. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#ProvideCorrectRegexPatternRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ProvideValidXmlStringRule">
		<name>ProvideValidXmlStringRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule verifies that valid XML string arguments are passed as arguments. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#ProvideValidXmlStringRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ProvideValidXPathExpressionRule">
		<name>ProvideValidXPathExpressionRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule verifies that valid XPath expression strings are passed as arguments. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#ProvideValidXPathExpressionRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ReviewCastOnIntegerDivisionRule">
		<name>ReviewCastOnIntegerDivisionRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for integral divisions where the result is cast to a floating point type. It's usually best to instead cast an operand to the floating point type so that the result is not truncated. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#ReviewCastOnIntegerDivisionRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ReviewCastOnIntegerMultiplicationRule">
		<name>ReviewCastOnIntegerMultiplicationRule</name>
		<configKey><![CDATA[ReviewCastOnIntegerMultiplicationRule@Gendarme.Rules.Correctness.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for integral multiply operations where the result is cast to a larger integral type. It's safer instead to cast an operand to the larger type to minimize the chance of overflow. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#ReviewCastOnIntegerMultiplicationRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ReviewDoubleAssignmentRule">
		<name>ReviewDoubleAssignmentRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for variables or fields that are assigned multiple times using the same value. This won't change the value of the variable (or fields) but should be reviewed since it could be a typo that hides a real issue in the code. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#ReviewDoubleAssignmentRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ReviewInconsistentIdentityRule">
		<name>ReviewInconsistentIdentityRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks to see if a type manages its identity in a consistent way. It checks: <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#ReviewInconsistentIdentityRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ReviewSelfAssignmentRule">
		<name>ReviewSelfAssignmentRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for variables or fields that are assigned to themselves. This won't change the value of the variable (or fields) but should be reviewed since it could be a typo that hides a real issue in the code. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#ReviewSelfAssignmentRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ReviewUselessControlFlowRule">
		<name>ReviewUselessControlFlowRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for empty blocks that produce useless control flow inside IL. This usually occurs when a block is left incomplete or when a typo is made. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#ReviewUselessControlFlowRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ReviewUseOfInt64BitsToDoubleRule">
		<name>ReviewUseOfInt64BitsToDoubleRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for invalid integer to double conversion using the, confusingly named, <b>BitConverter.Int64BitsToDouble</b> method. This method converts the actual bits, i.e. not the value, into a <b>Double</b>. The rule will warn when anything other than an <b>Int64</b> is being used as a parameter to this method. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#ReviewUseOfInt64BitsToDoubleRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ReviewUseOfModuloOneOnIntegersRule">
		<name>ReviewUseOfModuloOneOnIntegersRule</name>
		<configKey><![CDATA[ReviewUseOfModuloOneOnIntegersRule@Gendarme.Rules.Correctness.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for a modulo one (1) operation on an integral type. This is most likely a typo since the result is always 0. This usually happen when someone confuses a bitwise operation with a remainder. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#ReviewUseOfModuloOneOnIntegersRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseValueInPropertySetterRule">
		<name>UseValueInPropertySetterRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule ensures all setter properties uses the value argument passed to the property. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Correctness#UseValueInPropertySetterRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidAssemblyVersionMismatchRule">
		<name>AvoidAssemblyVersionMismatchRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks that the <b>[AssemblyVersion]</b> matches the <b>[AssemblyFileVersion]</b> when both are present inside an assembly. Having different version numbers in both attributes can be confusing once the application is deployed. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#AvoidAssemblyVersionMismatchRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidCallingProblematicMethodsRule">
		<name>AvoidCallingProblematicMethodsRule</name>
		<configKey><![CDATA[AvoidCallingProblematicMethodsRule@Gendarme.Rules.BadPractice.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule warns about methods that calls into potentially dangerous API of the .NET framework. If possible try to avoid the API (there are generally safer ways to do the same) or at least make sure your code can be safely called from others. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#AvoidCallingProblematicMethodsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidVisibleConstantFieldRule">
		<name>AvoidVisibleConstantFieldRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule looks for constant fields which are visible outside the current assembly. Such fields, if used outside the assemblies, will have their value (not the field reference) copied into the other assembly. Changing the field's value requires that all assemblies which use the field to be recompiled. Declaring the field as <b>static readonly</b>, on the other hand, allows the value to be changed without requiring that client assemblies be recompiled. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#AvoidVisibleConstantFieldRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="CheckNewExceptionWithoutThrowingRule">
		<name>CheckNewExceptionWithoutThrowingRule</name>
		<configKey><![CDATA[CheckNewExceptionWithoutThrowingRule@Gendarme.Rules.BadPractice.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for exception objects which are created but not thrown, not returned, and not passed to another method as an argument. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#CheckNewExceptionWithoutThrowingRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="CheckNewThreadWithoutStartRule">
		<name>CheckNewThreadWithoutStartRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for threads which are created but not started, or returned or passed to another method as an argument. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#CheckNewThreadWithoutStartRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="CloneMethodShouldNotReturnNullRule">
		<name>CloneMethodShouldNotReturnNullRule</name>
		<configKey><![CDATA[CloneMethodShouldNotReturnNullRule@Gendarme.Rules.BadPractice.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for <b>Clone()</b> methods which return <b>null</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#CloneMethodShouldNotReturnNullRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ConstructorShouldNotCallVirtualMethodsRule">
		<name>ConstructorShouldNotCallVirtualMethodsRule</name>
		<configKey><![CDATA[ConstructorShouldNotCallVirtualMethodsRule@Gendarme.Rules.BadPractice.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule warns the developer if any virtual methods are called in the constructor of a non-sealed type. The problem is that if a derived class overrides the method then that method will be called before the derived constructor has had a chance to run. This makes the code quite fragile. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#ConstructorShouldNotCallVirtualMethodsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DisableDebuggingCodeRule">
		<name>DisableDebuggingCodeRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for non-console applications which contain calls to <b>Console.WriteLine</b>. These are often used as debugging aids but such code should be removed or disabled in the released version. If you don't want to remove it altogether you can place it inside a method decorated with <b>[Conditional ("DEBUG")]</b>, use <b>Debug.WriteLine</b>, use <b>Trace.WriteLine</b>, or use the preprocessor. But note that TRACE is often enabled in release builds so if you do use that you'll probably want to use a config file to remove the default trace listener. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#DisableDebuggingCodeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotForgetNotImplementedMethodsRule">
		<name>DoNotForgetNotImplementedMethodsRule</name>
		<configKey><![CDATA[DoNotForgetNotImplementedMethodsRule@Gendarme.Rules.BadPractice.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for short methods that throw a <b>System.NotImplementedException</b> exception. It's likely a method that has not yet been implemented and should not be forgotten by the developer before a release. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#DoNotForgetNotImplementedMethodsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotUseEnumIsAssignableFromRule">
		<name>DoNotUseEnumIsAssignableFromRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for calls to <b>typeof (Enum).IsAssignableFrom (type)</b> that can be simplified to <b>type.IsEnum</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#DoNotUseEnumIsAssignableFromRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotUseGetInterfaceToCheckAssignabilityRule">
		<name>DoNotUseGetInterfaceToCheckAssignabilityRule</name>
		<configKey><![CDATA[DoNotUseGetInterfaceToCheckAssignabilityRule@Gendarme.Rules.BadPractice.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for calls to <b>Type.GetInterface</b> that look like they query if a type is supported, i.e. the result is only used to compare against <b>null</b>. The problem is that only assembly qualified names uniquely identify a type so if you just use the interface name or even just the name and namespace you may get unexpected results. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#DoNotUseGetInterfaceToCheckAssignabilityRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="EqualsShouldHandleNullArgRule">
		<name>EqualsShouldHandleNullArgRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule ensures that <b>Equals(object)</b> methods return <b>false</b> when the object parameter is <b>null</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#EqualsShouldHandleNullArgRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="GetEntryAssemblyMayReturnNullRule">
		<name>GetEntryAssemblyMayReturnNullRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule warns when an assembly without an entry point (i.e. a dll or library) calls <b>Assembly.GetEntryAssembly ()</b>. This call is problematic since it will always return <b>null</b> when called from outside the root (main) application domain. This may become a problem inside libraries that can be used, for example, inside ASP.NET applications. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#GetEntryAssemblyMayReturnNullRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ObsoleteMessagesShouldNotBeEmptyRule">
		<name>ObsoleteMessagesShouldNotBeEmptyRule</name>
		<configKey><![CDATA[ObsoleteMessagesShouldNotBeEmptyRule@Gendarme.Rules.BadPractice.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule warns if any type (including classes, structs, enums, interfaces and delegates), field, property, events, method and constructor are decorated with an empty <b>[Obsolete]</b> attribute because the attribute is much more helpful if it includes advice on how to deal with the situation (e.g. the new recommended API to use). <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#ObsoleteMessagesShouldNotBeEmptyRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="OnlyUseDisposeForIDisposableTypesRule">
		<name>OnlyUseDisposeForIDisposableTypesRule</name>
		<configKey><![CDATA[OnlyUseDisposeForIDisposableTypesRule@Gendarme.Rules.BadPractice.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[To avoid confusing developers methods named Dispose should be reserved for types that implement IDisposable. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#OnlyUseDisposeForIDisposableTypesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="PreferEmptyInstanceOverNullRule">
		<name>PreferEmptyInstanceOverNullRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks that all methods and properties which return a string, an array, a collection, or an enumerable do not return <b>null</b>. It is usually better to return an empty instance, as this allows the caller to use the result without having to perform a null-check first. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#PreferEmptyInstanceOverNullRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="PreferSafeHandleRule">
		<name>PreferSafeHandleRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[In general it is best to interop with native code using <b>System.Runtime.InteropServices.SafeHandle</b> instead of <b>System.IntPtr</b> or <b>System.UIntPtr</b> because: <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#PreferSafeHandleRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ReplaceIncompleteOddnessCheckRule">
		<name>ReplaceIncompleteOddnessCheckRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for problematic oddness checks. Often this is done by comparing a value modulo two (% 2) with one (1). However this will not work if the value is negative because negative one will be returned. A better (and faster) approach is to check the least significant bit of the integer. <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#ReplaceIncompleteOddnessCheckRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ToStringShouldNotReturnNullRule">
		<name>ToStringShouldNotReturnNullRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for overridden <b>ToString()</b> methods which return <b>null</b>. An appropriately descriptive string, or <b>string.Empty</b>, should be returned instead in order to make the value more useful (especially in debugging). <br/><a href="http://www.mono-project.com/Gendarme.Rules.BadPractice#ToStringShouldNotReturnNullRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotLockOnThisOrTypesRule">
		<name>DoNotLockOnThisOrTypesRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks if you're using <b>lock</b> on the current instance (<b>this</b>) or on a <b>Type</b>. This can cause problems because anyone can acquire a lock on the instance or type. And if another thread does acquire a lock then deadlocks become a very real possibility. The preferred way to handle this is to create a private <b>System.Object</b> instance field and <b>lock</b> that. This greatly reduces the scope of the code which may acquire the lock which makes it much easier to ensure that the locking is done correctly. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Concurrency#DoNotLockOnThisOrTypesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotLockOnWeakIdentityObjectsRule">
		<name>DoNotLockOnWeakIdentityObjectsRule</name>
		<configKey><![CDATA[DoNotLockOnWeakIdentityObjectsRule@Gendarme.Rules.Concurrency.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule ensures there are no locks on objects with weak identity. An object with weak identity is one that can be directly accessed across different application domains. Because these objects can be accessed by different application domains it is very difficult to ensure that the locking is done correctly so problems such as deadlocks are much more likely. The following types have a weak identities: <br/><a href="http://www.mono-project.com/Gendarme.Rules.Concurrency#DoNotLockOnWeakIdentityObjectsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotUseLockedRegionOutsideMethodRule">
		<name>DoNotUseLockedRegionOutsideMethodRule</name>
		<configKey><![CDATA[DoNotUseLockedRegionOutsideMethodRule@Gendarme.Rules.Concurrency.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire if a method calls <b>System.Threading.Monitor.Enter</b>, but not <b>System.Threading.Monitor.Exit</b>. This is a bad idea for public methods because the callers must (indirectly) manage a lock which they do not own. This increases the potential for problems such as dead locks because locking/unlocking may not be done together, the callers must do the unlocking even in the presence of exceptions, and it may not be completely clear that the public method is acquiring a lock without releasing it. This is less of a problem for private methods because the lock is managed by code that owns the lock. So, it's relatively easy to analyze the class to ensure that the lock is locked and unlocked correctly and that any invariants are preserved when the lock is acquired and after it is released. However it is usually simpler and more maintainable if methods unlock whatever they lock. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Concurrency#DoNotUseLockedRegionOutsideMethodRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotUseMethodImplOptionsSynchronizedRule">
		<name>DoNotUseMethodImplOptionsSynchronizedRule</name>
		<configKey><![CDATA[DoNotUseMethodImplOptionsSynchronizedRule@Gendarme.Rules.Concurrency.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if a method is decorated with <b>[MethodImpl(MethodImplOptions.Synchronized)]</b>. The runtime synchronizes those methods automatically using a <b>lock(this)</b> for instance methods or a <b>lock(typeof(X))</b> for static methods. This can cause problems because anyone can acquire a lock on the instance or type. And if another thread does acquire a lock then deadlocks become a very real possibility. The preferred way to handle this is to create a private <b>System.Object</b> instance field and <b>lock</b> that. This greatly reduces the scope of the code which may acquire the lock which makes it much easier to ensure that the locking is done correctly. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Concurrency#DoNotUseMethodImplOptionsSynchronizedRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotUseThreadStaticWithInstanceFieldsRule">
		<name>DoNotUseThreadStaticWithInstanceFieldsRule</name>
		<configKey><![CDATA[DoNotUseThreadStaticWithInstanceFieldsRule@Gendarme.Rules.Concurrency.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire if an instance field is decorated with a <b>[ThreadStatic]</b> attribute. This is an error because the attribute will only work with static fields. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Concurrency#DoNotUseThreadStaticWithInstanceFieldsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoubleCheckLockingRule">
		<name>DoubleCheckLockingRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule is used to check for the double-check pattern, often used when implementing the singleton pattern (1), and warns of potential incorrect usage. The original CLR (1.x) could not guarantee that a double-check would work correctly in multithreaded applications. However the technique does work on the x86 architecture, the most common architecture, so the problem is seldom seen (e.g. IA64). The CLR 2 and later introduce a strong memory model (2) where a double check for a <b>lock</b> is correct (as long as you assign to a <b>volatile</b> variable). This rule won't report a defect for assemblies targetting the 2.0 (and later) runtime. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Concurrency#DoubleCheckLockingRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="NonConstantStaticFieldsShouldNotBeVisibleRule">
		<name>NonConstantStaticFieldsShouldNotBeVisibleRule</name>
		<configKey><![CDATA[NonConstantStaticFieldsShouldNotBeVisibleRule@Gendarme.Rules.Concurrency.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule warns if a non-constant public static field is found. In a multi-threaded environment access to those fields must be synchronized. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Concurrency#NonConstantStaticFieldsShouldNotBeVisibleRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ProtectCallToEventDelegatesRule">
		<name>ProtectCallToEventDelegatesRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks that event invocations are safely implemented. In particular, the event must be copied into a local to avoid race conditions and it must be checked for null before it is used (events will normally be null until a delegate is added to them). <br/><a href="http://www.mono-project.com/Gendarme.Rules.Concurrency#ProtectCallToEventDelegatesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ReviewLockUsedOnlyForOperationsOnVariablesRule">
		<name>ReviewLockUsedOnlyForOperationsOnVariablesRule</name>
		<configKey><![CDATA[ReviewLockUsedOnlyForOperationsOnVariablesRule@Gendarme.Rules.Concurrency.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks if a lock is used only to perform operations on locals or fields. If the only purpose of that critical section is to make sure the variables are modified atomatically then the methods provided by System.Threading.Interlocked class will be more efficient. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Concurrency#ReviewLockUsedOnlyForOperationsOnVariablesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="WriteStaticFieldFromInstanceMethodRule">
		<name>WriteStaticFieldFromInstanceMethodRule</name>
		<configKey><![CDATA[WriteStaticFieldFromInstanceMethodRule@Gendarme.Rules.Concurrency.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule is used to check for instance methods which write values to static fields. This may cause problems if multiple instances of the type exist and are used in multithreaded applications. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Concurrency#WriteStaticFieldFromInstanceMethodRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AbstractTypesShouldNotHavePublicConstructorsRule">
		<name>AbstractTypesShouldNotHavePublicConstructorsRule</name>
		<configKey><![CDATA[AbstractTypesShouldNotHavePublicConstructorsRule@Gendarme.Rules.Design.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if an <b>abstract</b> type has a <b>public</b> constructor. This is a bit misleading because the constructor can only be called by the constructor of a derived type. To make the type's semantics clearer make the constructor <b>protected</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#AbstractTypesShouldNotHavePublicConstructorsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AttributeArgumentsShouldHaveAccessorsRule">
		<name>AttributeArgumentsShouldHaveAccessorsRule</name>
		<configKey><![CDATA[AttributeArgumentsShouldHaveAccessorsRule@Gendarme.Rules.Design.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if a parameter to an <b>Attribute</b> constructor is not exposed using a properly cased property. This is a problem because it is generally not useful to set state within an attribute without providing a way to get at that state. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#AttributeArgumentsShouldHaveAccessorsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidEmptyInterfaceRule">
		<name>AvoidEmptyInterfaceRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if an interface declares no members. Empty interfaces are generally not useful except as markers to categorize types and attributes are the preferred way to handle that. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#AvoidEmptyInterfaceRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidMultidimensionalIndexerRule">
		<name>AvoidMultidimensionalIndexerRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for externally visible indexer properties which have more than one index argument. These can be confusing to some developers and IDEs with auto-complete don't always handle them as well as methods so it can be hard to know which argument is which. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#AvoidMultidimensionalIndexerRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidPropertiesWithoutGetAccessorRule">
		<name>AvoidPropertiesWithoutGetAccessorRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if an externally visible type contains a property with a setter but not a getter. This is confusing to users and can make it difficult to use shared objects. Instead either add a getter or make the property a method. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#AvoidPropertiesWithoutGetAccessorRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidRefAndOutParametersRule">
		<name>AvoidRefAndOutParametersRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if a method uses <b>ref</b> or <b>out</b> parameters. These are advanced features that can easily be misunderstood (by the consumer) and misused (by the consumer) and can result in an API that is difficult to use. Avoid them whenever possible or, if needed, provide simpler alternatives for most use cases. An exception is made, i.e. no defect are reported, for the <b>bool Try*(X out)</b> pattern. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#AvoidRefAndOutParametersRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidSmallNamespaceRule">
		<name>AvoidSmallNamespaceRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if a namespace contains less than five (by default) visible types. Note that this rule enumerates the types in all the assemblies being analyzed instead of simply considering each assembly in turn.<br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#AvoidSmallNamespaceRule">Link to the official Mono Gendarme documentation</a>]]></description>
		<param key="Minimum" type="i">
			<description><![CDATA[The minimum number of types which must exist within a namespace. Default is 5.]]></description>
		</param>
	</rule>
	<rule key="AvoidVisibleFieldsRule">
		<name>AvoidVisibleFieldsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if a type contains externally visible fields. Instead use a property which allows you to change the implementation without breaking binary compatibility with other assemblies. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#AvoidVisibleFieldsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidVisibleNestedTypesRule">
		<name>AvoidVisibleNestedTypesRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for nested types which are externally visible. Such types are often confused with namespaces which makes them more difficult to document and find by developers. In most cases it is better to make these types private or to scope them within a namespace instead of a type. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#AvoidVisibleNestedTypesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ConsiderAddingInterfaceRule">
		<name>ConsiderAddingInterfaceRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if a type implements members which are declared in an interface, but the type does not implement the interface. Implementing the interface will normally make the type more reuseable and will help clarify the type's semantics. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#ConsiderAddingInterfaceRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ConsiderConvertingFieldToNullableRule">
		<name>ConsiderConvertingFieldToNullableRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for pairs of fields which seem to provide the same functionality as a single nullable field. If the assembly targets version 2.0, or more recent, of the CLR then the rule will fire to let you know that a nullable field can be used instead. The rule will ignore assemblies targeting earlier versions of the CLR. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#ConsiderConvertingFieldToNullableRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ConsiderConvertingMethodToPropertyRule">
		<name>ConsiderConvertingMethodToPropertyRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for methods whose definition looks similar to a property. For example, methods beginning with <b>Is</b>, <b>Get</b> or <b>Set</b> may be better off as properties. But note that this should not be done if the method takes a non-trivial amount of time to execute. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#ConsiderConvertingMethodToPropertyRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ConsiderUsingStaticTypeRule">
		<name>ConsiderUsingStaticTypeRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for types that contain only static members and, if the assembly targets the CLR version 2.0 or later, suggests that the type be made <b>static</b>. The rule will ignore assemblies targeting earlier versions of the CLR. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#ConsiderUsingStaticTypeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DeclareEventHandlersCorrectlyRule">
		<name>DeclareEventHandlersCorrectlyRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire if an event is declared with a signature which does not match the .NET guidelines. The return type of the event should be void (because there is no good way to handle return values if multiple delegates are attached to the event). And the event should take two arguments. The first should be of type <b>System.Object</b> and be named 'sender'. The second should be of type <b>System.EventArgs</b> (or a subclass) and named 'e'. This helps tools such as visual designers identify the delegates and methods which may be attached to events. Note that .NET 2.0 added a generic <b>System.EventHandler</b>type which can be used to easily create events with the correct signature. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#DeclareEventHandlersCorrectlyRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DisposableTypesShouldHaveFinalizerRule">
		<name>DisposableTypesShouldHaveFinalizerRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire for types which implement <b>System.IDisposable</b>, contain native fields such as <b>System.IntPtr</b>, <b>System.UIntPtr</b>, and <b>System.Runtime.InteropServices.HandleRef</b>, but do not define a finalizer. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#DisposableTypesShouldHaveFinalizerRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotDeclareProtectedMembersInSealedTypeRule">
		<name>DoNotDeclareProtectedMembersInSealedTypeRule</name>
		<configKey><![CDATA[DoNotDeclareProtectedMembersInSealedTypeRule@Gendarme.Rules.Design.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule ensures that <b>sealed</b> types (i.e. types that you can't inherit from) do not define family (<b>protected</b> in C#) fields or methods. Instead make the member private so that its accessibility is not misleading. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#DoNotDeclareProtectedMembersInSealedTypeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotDeclareVirtualMethodsInSealedTypeRule">
		<name>DoNotDeclareVirtualMethodsInSealedTypeRule</name>
		<configKey><![CDATA[DoNotDeclareVirtualMethodsInSealedTypeRule@Gendarme.Rules.Design.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule ensure that <b>sealed</b> types (i.e. types that you can't inherit from) do not define new <b>virtual</b> methods. Such methods would only be useful in sub-types. Note that some compilers, like C# and VB.NET compilers, do not allow you to define such methods. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#DoNotDeclareVirtualMethodsInSealedTypeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="EnsureSymmetryForOverloadedOperatorsRule">
		<name>EnsureSymmetryForOverloadedOperatorsRule</name>
		<configKey><![CDATA[EnsureSymmetryForOverloadedOperatorsRule@Gendarme.Rules.Design.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for operators that are not overloaded in pairs. Some compilers, like the C# compilers, require you to implement some of the pairs, but other languages might not. The following pairs are checked: <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#EnsureSymmetryForOverloadedOperatorsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="EnumsShouldDefineAZeroValueRule">
		<name>EnumsShouldDefineAZeroValueRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule ensures that every non-flags enumeration contains a <b>0</b> value. This is important because if a field is not explicitly initialized .NET will zero-initialize it and, if the enum has no zero value, then it will be initialized to an invalid value. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#EnumsShouldDefineAZeroValueRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="EnumsShouldUseInt32Rule">
		<name>EnumsShouldUseInt32Rule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[Enumaration types should avoid specifying a non-default storage type for their values unless it is required for interoperability (e.g. with native code). If you do use a non-default type for the enum, and the enum is externally visible, then prefer the CLS-compliant integral types: System.Byte, System.Int16, System.Int32, and System.Int64. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#EnumsShouldUseInt32Rule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="FinalizersShouldBeProtectedRule">
		<name>FinalizersShouldBeProtectedRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule verifies that finalizers are only visible to the type's family (e.g. protected in C#). If they are not family then they can be called from user code which could lead to problems. Note that this restriction is enforced by the C# and VB.NET compilers but other compilers may not do so. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#FinalizersShouldBeProtectedRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="FlagsShouldNotDefineAZeroValueRule">
		<name>FlagsShouldNotDefineAZeroValueRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule ensures that enumerations decorated with the [System.Flags] attribute do not contain a 0 value. This value would not be usable with bitwise operators. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#FlagsShouldNotDefineAZeroValueRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ImplementEqualsAndGetHashCodeInPairRule">
		<name>ImplementEqualsAndGetHashCodeInPairRule</name>
		<configKey><![CDATA[ImplementEqualsAndGetHashCodeInPairRule@Gendarme.Rules.Design.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for types that either override the <b>Equals(object)</b> method without overriding <b>GetHashCode()</b> or override <b>GetHashCode</b> without overriding <b>Equals</b>. In order to work correctly types should always override these together. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#ImplementEqualsAndGetHashCodeInPairRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ImplementICloneableCorrectlyRule">
		<name>ImplementICloneableCorrectlyRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if you implement a <b>object Clone()</b> method without implementing the <b>System.ICloneable</b> interface. Either change the method so that it returns a better type than System.Object or implement ICloneable. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#ImplementICloneableCorrectlyRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ImplementIComparableCorrectlyRule">
		<name>ImplementIComparableCorrectlyRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for types that implement <b>System.IComparable</b> and verifies that the type overrides the <b>Equals(object)</b> method and overloads the <b>==</b>, <b>!=</b>, <b>&amp;lt;</b> and <b>&amp;gt;</b> operators. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#ImplementIComparableCorrectlyRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="InternalNamespacesShouldNotExposeTypesRule">
		<name>InternalNamespacesShouldNotExposeTypesRule</name>
		<configKey><![CDATA[InternalNamespacesShouldNotExposeTypesRule@Gendarme.Rules.Design.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for externally visible types that reside inside internal namespaces, i.e. namespaces ending with <b>Internal</b> or <b>Impl</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#InternalNamespacesShouldNotExposeTypesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MainShouldNotBePublicRule">
		<name>MainShouldNotBePublicRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if an assembly's entry point (typically named <b>Main</b>) is visible to other assemblies. It is better to make this method private so that only the CLR can call the method. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#MainShouldNotBePublicRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MarkAssemblyWithAssemblyVersionRule">
		<name>MarkAssemblyWithAssemblyVersionRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if an assembly does not contain a <b>[AssemblyVersion]</b>attribute. Early and correct versioning of assemblies is easy and crucial for consumers of your assemblies. Note that the <b>[AssemblyVersion]</b> should match the <b>[AssemblyFileVersion]</b> attribute (if it exists). <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#MarkAssemblyWithAssemblyVersionRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MarkAssemblyWithCLSCompliantRule">
		<name>MarkAssemblyWithCLSCompliantRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if an assembly does not contain a <b>[CLSCompliant]</b> attribute. CLS compliant assemblies can be reused by any CLS-compliant language. It is a good practice to declare your global CLS goal at the assembly level and, if needed, mark some types or members that behave differently inside your assembly. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#MarkAssemblyWithCLSCompliantRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MarkAssemblyWithComVisibleRule">
		<name>MarkAssemblyWithComVisibleRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if an assembly does not contain a <b>[ComVisible]</b> attribute. Unless the assembly is designed with COM interoperability in mind it is better to declare it as non-COM visible, i.e. <b>[ComVisible (false)]</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#MarkAssemblyWithComVisibleRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MissingAttributeUsageOnCustomAttributeRule">
		<name>MissingAttributeUsageOnCustomAttributeRule</name>
		<configKey><![CDATA[MissingAttributeUsageOnCustomAttributeRule@Gendarme.Rules.Design.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule verifies that every custom attribute (i.e. types that inherit from <b>System.Attribute</b>) is decorated with an <b>[AttributeUsage]</b> attribute to specify which kind of code instances of that custom attribute can be applied to. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#MissingAttributeUsageOnCustomAttributeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="OperatorEqualsShouldBeOverloadedRule">
		<name>OperatorEqualsShouldBeOverloadedRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if a type overloads operator add <b>+</b>, or overloads operator subtract <b>-</b>, or is a value type and overrides <b>Object.Equals</b>, but equals <b>==</b> is not overloaded. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#OperatorEqualsShouldBeOverloadedRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="OverrideEqualsMethodRule">
		<name>OverrideEqualsMethodRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule warns when a type overloads the equality <b>==</b> operator but does not override the <b>Object.Equals</b> method. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#OverrideEqualsMethodRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="PreferEventsOverMethodsRule">
		<name>PreferEventsOverMethodsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for method names that suggest they are providing similar functionality to .NET events. When possible the method(s) should be replaced with a real event. If the methods are not using or providing event-like features then they should be renamed since such names can confuse consumers about what the method is really doing. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#PreferEventsOverMethodsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="PreferIntegerOrStringForIndexersRule">
		<name>PreferIntegerOrStringForIndexersRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for indexer properties which use unusual types as indexes. Recommended types include <b>Int32</b>, <b>Int64</b> and <b>String</b>. Using other types can be OK if the indexer is providing an abstraction onto a logical data store, but this is often not the case. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#PreferIntegerOrStringForIndexersRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="PreferXmlAbstractionsRule">
		<name>PreferXmlAbstractionsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if an externally visible method or property uses an <b>XmlDocument</b>, <b>XPathDocument</b> or <b>XmlNode</b> argument. The problem with this is that it ties your API to a specific implementation so it is difficult to change later. Instead use abstract types like <b>IXPathNavigable</b>, <b>XmlReader</b>, <b>XmlWriter</b>, or subtypes of <b>XmlNode</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#PreferXmlAbstractionsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ProvideAlternativeNamesForOperatorOverloadsRule">
		<name>ProvideAlternativeNamesForOperatorOverloadsRule</name>
		<configKey><![CDATA[ProvideAlternativeNamesForOperatorOverloadsRule@Gendarme.Rules.Design.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[The rule ensure that all overloaded operators are also accessible using named alternatives because some languages, like VB.NET, cannot use overloaded operators. For those languages named methods should be implemented that provide the same functionality. This rule verifies that a named alternative exists for each overloaded operator. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#ProvideAlternativeNamesForOperatorOverloadsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="TypesShouldBeInsideNamespacesRule">
		<name>TypesShouldBeInsideNamespacesRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire if a type which is visible outside the assembly is not declared within a namespace. Using namespaces greatly reduces the probability of name collisions, allows tools such as auto-complete to operate better, and can make the assemblies API clearer. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#TypesShouldBeInsideNamespacesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="TypesWithDisposableFieldsShouldBeDisposableRule">
		<name>TypesWithDisposableFieldsShouldBeDisposableRule</name>
		<configKey><![CDATA[TypesWithDisposableFieldsShouldBeDisposableRule@Gendarme.Rules.Design.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire if a type contains disposable fields but does not implement <b>System.IDisposable</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#TypesWithDisposableFieldsShouldBeDisposableRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="TypesWithNativeFieldsShouldBeDisposableRule">
		<name>TypesWithNativeFieldsShouldBeDisposableRule</name>
		<configKey><![CDATA[TypesWithNativeFieldsShouldBeDisposableRule@Gendarme.Rules.Design.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire if a type contains <b>IntPtr</b>, <b>UIntPtr</b>, or <b>HandleRef</b> fields but does not implement <b>System.IDisposable</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#TypesWithNativeFieldsShouldBeDisposableRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseCorrectDisposeSignaturesRule">
		<name>UseCorrectDisposeSignaturesRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[There is a convention that should be followed when implementing <b>IDisposable</b>. Part of this convention is that Dispose methods should have specific signatures. In particular an <b>IDisposable</b> type's Dispose methods should either be nullary or unary with a bool argument, <b>Dispose ()</b> should not be virtual, <b>Dispose (bool)</b> should not be public, and unsealed types should have a <b>protected virtual Dispose (bool)</b> method. For more details see: <a href="http://www.bluebytesoftware.com/blog/2005/04/08/DGUpdateDisposeFinalizationAndResourceManagement.aspx" class="external" title="http://www.bluebytesoftware.com/blog/2005/04/08/DGUpdateDisposeFinalizationAndResourceManagement.aspx" rel="nofollow">[1]</a><span class="urlexpansion">&amp;nbsp;(<i>http://www.bluebytesoftware.com/blog/2005/04/08/DGUpdateDisposeFinalizationAndResourceManagement.aspx</i>)</span>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#UseCorrectDisposeSignaturesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseFlagsAttributeRule">
		<name>UseFlagsAttributeRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire if an enum's values look like they are intended to be composed together with the bitwise OR operator and the enum is not decorated with <b>System.FlagsAttribute</b>. Using <b>FlagsAttribute</b> will allow <b>System.Enum.ToString()</b> to return a better string when values are ORed together and helps indicate to readers of the code the intended usage of the enum. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design#UseFlagsAttributeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidMethodWithUnusedGenericTypeRule">
		<name>AvoidMethodWithUnusedGenericTypeRule</name>
		<configKey><![CDATA[AvoidMethodWithUnusedGenericTypeRule@Gendarme.Rules.Design.Generic.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This method will fire if a generic method does not use all of its generic type parameters in the formal parameter list. This usually means that either the type parameter is not used at all in which case it should be removed or that it's used only for the return type which is problematic because that prevents the compiler from inferring the generic type when the method is called which is confusing to many developers. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design.Generic#AvoidMethodWithUnusedGenericTypeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotExposeNestedGenericSignaturesRule">
		<name>DoNotExposeNestedGenericSignaturesRule</name>
		<configKey><![CDATA[DoNotExposeNestedGenericSignaturesRule@Gendarme.Rules.Design.Generic.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire if an externally visible method has a parameter or return type whose type is a generic type which contains a generic type. For example, <b>List&amp;lt;List&amp;lt;int&amp;gt;&amp;gt;</b>. Such types are hard to construct and should be avoided because simpler alternatives generally exist. Since some language, like C#, have direct support for nullable types, i.e. <b>Nullable&amp;lt;T&amp;gt;</b> this specific case is ignored by the rule. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design.Generic#DoNotExposeNestedGenericSignaturesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ImplementGenericCollectionInterfacesRule">
		<name>ImplementGenericCollectionInterfacesRule</name>
		<configKey><![CDATA[ImplementGenericCollectionInterfacesRule@Gendarme.Rules.Design.Generic.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for types which implement the non-generic IEnumerable interface but not the IEnumerable&amp;lt;T&amp;gt; interface. Implementing the generic version of IEnumerable avoids casts, and possibly boxing, when iterating the collection. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design.Generic#ImplementGenericCollectionInterfacesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="PreferGenericsOverRefObjectRule">
		<name>PreferGenericsOverRefObjectRule</name>
		<configKey><![CDATA[PreferGenericsOverRefObjectRule@Gendarme.Rules.Design.Generic.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if a method has a reference argument (<b>ref</b> or <b>out</b> in C#) to System.Object. These methods can generally be rewritten in .NET 2.0 using generics which provides type safety, eliminates casts, and makes the API easier to consume. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design.Generic#PreferGenericsOverRefObjectRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseGenericEventHandlerRule">
		<name>UseGenericEventHandlerRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule fires if an assembly targets .NET 2.0 or later and defines a delegate which can be replaced by <b>System.EventHandler&amp;lt;TEventArgs&amp;gt;</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design.Generic#UseGenericEventHandlerRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidExtensionMethodOnSystemObjectRule">
		<name>AvoidExtensionMethodOnSystemObjectRule</name>
		<configKey><![CDATA[AvoidExtensionMethodOnSystemObjectRule@Gendarme.Rules.Design.Linq.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[Extension methods should not be used to extend <b>System.Object</b>. Such extension methods cannot be consumed by some languages, like VB.NET, which use late-binding on <b>System.Object</b> instances. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Design.Linq#AvoidExtensionMethodOnSystemObjectRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidArgumentExceptionDefaultConstructorRule">
		<name>AvoidArgumentExceptionDefaultConstructorRule</name>
		<configKey><![CDATA[AvoidArgumentExceptionDefaultConstructorRule@Gendarme.Rules.Exceptions.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks that every <b>System.ArgumentException</b>, <b>System.ArgumentNullException</b>, <b>System.ArgumentOutOfRangeException</b>, or <b>System.DuplicateWaitObjectException</b> exception created is provided with some useful information about the exception being thrown, minimally the parameter name. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Exceptions#AvoidArgumentExceptionDefaultConstructorRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidThrowingBasicExceptionsRule">
		<name>AvoidThrowingBasicExceptionsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for methods that create basic exceptions like <b>System.Exception</b>, <b>System.ApplicationException</b> or <b>System.SystemException</b>. Those exceptions do not provide enough information about the error to be helpful to the consumer of the library. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Exceptions#AvoidThrowingBasicExceptionsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotDestroyStackTraceRule">
		<name>DoNotDestroyStackTraceRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire if a catch handler throws the exception it caught. What it should do instead is rethrow the original exception (e.g. use <b>throw</b> instead of <b>throw ex</b>). This is helpful because rethrow preserves the stacktrace of the original exception. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Exceptions#DoNotDestroyStackTraceRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotSwallowErrorsCatchingNonSpecificExceptionsRule">
		<name>DoNotSwallowErrorsCatchingNonSpecificExceptionsRule</name>
		<configKey><![CDATA[DoNotSwallowErrorsCatchingNonSpecificExceptionsRule@Gendarme.Rules.Exceptions.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire if a catch block catches <b>System.Exception</b> or <b>System.SystemException</b> but does not rethrow the original exception. This is problematic because you don't know what went wrong so it's difficult to know that the error was handled correctly. It is better to catch a more specific set of exceptions so that you do know what went wrong and do know that it is handled correctly. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Exceptions#DoNotSwallowErrorsCatchingNonSpecificExceptionsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotThrowInUnexpectedLocationRule">
		<name>DoNotThrowInUnexpectedLocationRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[There are a number of methods which have constraints on the exceptions which they may throw. This rule checks the following methods: <br/><a href="http://www.mono-project.com/Gendarme.Rules.Exceptions#DoNotThrowInUnexpectedLocationRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotThrowReservedExceptionRule">
		<name>DoNotThrowReservedExceptionRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire if an <b>System.ExecutionEngineException</b>, <b>System.IndexOutOfRangeException</b>, <b>NullReferenceException</b>, or <b>System.OutOfMemoryException</b> class is instantiated. These exceptions are for use by the runtime and should not be thrown by user code. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Exceptions#DoNotThrowReservedExceptionRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ExceptionShouldBeVisibleRule">
		<name>ExceptionShouldBeVisibleRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for non-visible exceptions which derive directly from the most basic exceptions: <b>System.Exception</b>, <b>System.ApplicationException</b>or <b>System.SystemException</b>. Those basic exceptions, being visible, will be the only information available to the API consumer - but do not contain enough data to be useful. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Exceptions#ExceptionShouldBeVisibleRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="InstantiateArgumentExceptionCorrectlyRule">
		<name>InstantiateArgumentExceptionCorrectlyRule</name>
		<configKey><![CDATA[InstantiateArgumentExceptionCorrectlyRule@Gendarme.Rules.Exceptions.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire if the arguments to the <b>System.ArgumentException</b>, <b>System.ArgumentNullException</b>, <b>System.ArgumentOutOfRangeException</b>, and <b>System.DuplicateWaitObjectException</b> constructors are used incorrectly. This is a common mistake because the position of the <b>parameterName</b> argument is not consistent across these types. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Exceptions#InstantiateArgumentExceptionCorrectlyRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MissingExceptionConstructorsRule">
		<name>MissingExceptionConstructorsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire if an exception class is missing one or more of the following constructors: <br/><a href="http://www.mono-project.com/Gendarme.Rules.Exceptions#MissingExceptionConstructorsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseObjectDisposedExceptionRule">
		<name>UseObjectDisposedExceptionRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[It's usually a very bad idea to attempt to use an object after it has been disposed. Doing so may lead to crashes in native code or any number of other problems. In order to prevent this, and to report the problem in a clear way, classes should throw System.ObjectDisposedException from public methods if the object has been disposed. Note that there are some methods which should not throw ObjectDisposedException. This includes constructors, finalizers, Equals, GetHashCode, ToString, and Dispose. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Exceptions#UseObjectDisposedExceptionRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DelegatesPassedToNativeCodeMustIncludeExceptionHandlingRule">
		<name>DelegatesPassedToNativeCodeMustIncludeExceptionHandlingRule
		</name>
		<configKey><![CDATA[DelegatesPassedToNativeCodeMustIncludeExceptionHandlingRule@Gendarme.Rules.Interoperability.dll]]></configKey>
		<category name="Portability" />
		<description><![CDATA[Every delegate which is passed to native code must include an exception block which spans the entire method and has a catch all handler. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Interoperability#DelegatesPassedToNativeCodeMustIncludeExceptionHandlingRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotAssumeIntPtrSizeRule">
		<name>DoNotAssumeIntPtrSizeRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Portability" />
		<description><![CDATA[This rule checks for code which casts an <b>IntPtr</b> or <b>UIntPtr</b> into a 32-bit (or smaller) value. It will also check if memory read with the <b>Marshal.ReadInt32</b>and <b>Marshal.ReadInt64</b> methods is being cast into an <b>IntPtr</b> or <b>UIntPtr</b>. <b>IntPtr</b> is generally used to reference a memory location and downcasting them to 32-bits will make the code fail on 64-bit CPUs. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Interoperability#DoNotAssumeIntPtrSizeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="GetLastErrorMustBeCalledRightAfterPInvokeRule">
		<name>GetLastErrorMustBeCalledRightAfterPInvokeRule</name>
		<configKey><![CDATA[GetLastErrorMustBeCalledRightAfterPInvokeRule@Gendarme.Rules.Interoperability.dll]]></configKey>
		<category name="Portability" />
		<description><![CDATA[This rule will fire if <b>Marshal.GetLastWin32Error()</b> is called, but is not called immediately after a P/Invoke. This is a problem because other methods, even managed methods, may overwrite the error code. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Interoperability#GetLastErrorMustBeCalledRightAfterPInvokeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MarshalBooleansInPInvokeDeclarationsRule">
		<name>MarshalBooleansInPInvokeDeclarationsRule</name>
		<configKey><![CDATA[MarshalBooleansInPInvokeDeclarationsRule@Gendarme.Rules.Interoperability.dll]]></configKey>
		<category name="Portability" />
		<description><![CDATA[This rule warns the developer if a <b>[MarshalAs]</b> attribute has not been specified for boolean parameters of a P/Invoke method. The size of boolean types varies across language (e.g. the C++ <b>bool</b> type is four bytes on some platforms and one byte on others). By default the CLR will marshal <b>System.Boolean</b>as a 32 bit value (<b>UnmanagedType.Bool</b>) like the Win32 API <b>BOOL</b>uses. But, for clarity, you should always specify the correct value. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Interoperability#MarshalBooleansInPInvokeDeclarationsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MarshalStringsInPInvokeDeclarationsRule">
		<name>MarshalStringsInPInvokeDeclarationsRule</name>
		<configKey><![CDATA[MarshalStringsInPInvokeDeclarationsRule@Gendarme.Rules.Interoperability.dll]]></configKey>
		<category name="Portability" />
		<description><![CDATA[This rule will fire if a P/Invoke method has System.String or System.Text.StringBuilder arguments, and the DllImportAttribute does not specify the <b>CharSet</b>, and the string arguments are not decorated with <b>[MarshalAs]</b>. This is important because the defaults are different on the various platforms. On Mono the default is to always use utf-8. On .NET the default is to use the ANSI CharSet which is the native encoding and will typically be some variant of ASCII or something like Shift-JIS. On Compact .NET the default is utf-16. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Interoperability#MarshalStringsInPInvokeDeclarationsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="PInvokeShouldNotBeVisibleRule">
		<name>PInvokeShouldNotBeVisibleRule</name>
		<configKey><![CDATA[PInvokeShouldNotBeVisibleRule@Gendarme.Rules.Interoperability.dll]]></configKey>
		<category name="Portability" />
		<description><![CDATA[This rule checks for PInvoke declaration methods that are visible outside their assembly. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Interoperability#PInvokeShouldNotBeVisibleRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseManagedAlternativesToPInvokeRule">
		<name>UseManagedAlternativesToPInvokeRule</name>
		<configKey><![CDATA[UseManagedAlternativesToPInvokeRule@Gendarme.Rules.Interoperability.dll]]></configKey>
		<category name="Portability" />
		<description><![CDATA[This rule will fire if an external (P/Invoke) method is called but a managed alternative is provided by the .NET framework. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Interoperability#UseManagedAlternativesToPInvokeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidAlwaysNullFieldRule">
		<name>AvoidAlwaysNullFieldRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[A type has a private field whose value is always null. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Maintainability#AvoidAlwaysNullFieldRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidComplexMethodsRule">
		<name>AvoidComplexMethodsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule computes the cyclomatic complexity (CC) for every method and reports any method with a CC over 25 (this limit is configurable). Large CC value often indicate complex code that is hard to understand and maintain. It's likely that breaking the method into several methods will help readability. This rule won't report any defects on code generated by the compiler or by tools. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Maintainability#AvoidComplexMethodsRule">Link to the official Mono Gendarme documentation</a>]]></description>
		<param key="SuccessThreshold" type="i">
			<description><![CDATA[The cyclomatic complexity at which defects begin to be reported. Default is 25.]]></description>
		</param>
	</rule>
	<rule key="AvoidDeepInheritanceTreeRule">
		<name>AvoidDeepInheritanceTreeRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule will fire if a type has (by default) more than four base classes defined within the assembly set being analyzed. Optionally it will also count base classes defined outside the assembly set being analyzed. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Maintainability#AvoidDeepInheritanceTreeRule">Link to the official Mono Gendarme documentation</a>]]></description>
		<param key="MaximumDepth" type="i">
			<description><![CDATA[Classes with more base classes than this will result in a defect. Default is 4.]]></description>
		</param>
	</rule>
	<rule key="AvoidLackOfCohesionOfMethodsRule">
		<name>AvoidLackOfCohesionOfMethodsRule</name>
		<configKey><![CDATA[AvoidLackOfCohesionOfMethodsRule@Gendarme.Rules.Maintainability.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks every type for lack of cohesion between the fields and the methods. Low cohesion is often a sign that a type is doing too many, different and unrelated things. The cohesion score is given for each defect (higher is better). <br/><a href="http://www.mono-project.com/Gendarme.Rules.Maintainability#AvoidLackOfCohesionOfMethodsRule">Link to the official Mono Gendarme documentation</a>]]></description>
		<param key="MinimumFieldCount" type="i">
			<description><![CDATA[The minimum number of fields a class must have to be checked. Default is 1]]></description>
		</param>
		<param key="MinimumMethodCount" type="i">
			<description><![CDATA[The minimum number of methods a class must have to be checked. Default is 2]]></description>
		</param>
	</rule>
	<rule key="AvoidUnnecessarySpecializationRule">
		<name>AvoidUnnecessarySpecializationRule</name>
		<configKey><![CDATA[AvoidUnnecessarySpecializationRule@Gendarme.Rules.Maintainability.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks methods for over specialized parameters - i.e. parameter types that are unnecessarily specialized with respect to what the method needs to perform its job. This often impairs the reusability of the method. If a problem is found the rule will suggest the most general type, or interface, required for the method to work. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Maintainability#AvoidUnnecessarySpecializationRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ConsiderUsingStopwatchRule">
		<name>ConsiderUsingStopwatchRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks methods for cases where a <b>System.Diagnostics.Stopwatch</b> could be used instead of using <b>System.DateTime</b> to compute the time required for an action. Stopwatch is preferred because it better expresses the intent of the code and because (on some platforms at least) StopWatch is accurate to roughly the microsecond whereas DateTime.Now is only accurate to 16 milliseconds or so. This rule only applies to assemblies compiled with the .NET framework version 2.0 (or later). <br/><a href="http://www.mono-project.com/Gendarme.Rules.Maintainability#ConsiderUsingStopwatchRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="PreferStringIsNullOrEmptyRule">
		<name>PreferStringIsNullOrEmptyRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks methods for cases where <b>String.IsNullOrEmpty</b> could be used instead of doing separate null and length checks. This does not affect execution nor performance (much) but it does improve source code readability. This rule only applies to assemblies compiled with .NET 2.0 (or later). <br/><a href="http://www.mono-project.com/Gendarme.Rules.Maintainability#PreferStringIsNullOrEmptyRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidDeepNamespaceHierarchyRule">
		<name>AvoidDeepNamespaceHierarchyRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Usability" />
		<description><![CDATA[This rule checks for deeply nested namespaces within an assembly. It will warn if the depth is greater than four (default value) unless the fifth (or the next) part is one of the specialized name that the framework recommends or a name like an internal namespace (something not meant to be seen outside the assembly). <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#AvoidDeepNamespaceHierarchyRule">Link to the official Mono Gendarme documentation</a>]]></description>
		<param key="MaxDepth" type="i">
			<description><![CDATA[The depth at which namespaces may be nested without triggering a defect. Default is 4.]]></description>
		</param>
	</rule>
	<rule key="AvoidNonAlphanumericIdentifierRule">
		<name>AvoidNonAlphanumericIdentifierRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Usability" />
		<description><![CDATA[This rule ensures that identifiers like assembly names, namespaces, types and members names don't have any non-alphanumerical characters inside them. The rule will ignore interfaces used for COM interoperability - i.e. decorated with both <b>[InterfaceType]</b> and <b>[Guid]</b> attributes. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#AvoidNonAlphanumericIdentifierRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidRedundancyInMethodNameRule">
		<name>AvoidRedundancyInMethodNameRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Usability" />
		<description><![CDATA[This rule will fire if a method name embeds the type name of its first parameter. Usually, removing that type name makes the API less verbose, easier to learn, and more future-proof. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#AvoidRedundancyInMethodNameRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidRedundancyInTypeNameRule">
		<name>AvoidRedundancyInTypeNameRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Usability" />
		<description><![CDATA[This rule will fire if a type is prefixed with the last component of its namespace. Using prefixes like this makes type names more verbose than they need to be and makes them harder to use with tools like auto-complete. Note that an exception is made if removal of the prefix would cause an ambiguity with another type. If this is the case the rule will not report a defect. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#AvoidRedundancyInTypeNameRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidTypeInterfaceInconsistencyRule">
		<name>AvoidTypeInterfaceInconsistencyRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Usability" />
		<description><![CDATA[This rule will fire if an assembly has a namespace which contains an interface IFoo and a type Foo, but the type does not implement the interface. If an interface and a type name differ only by the <b>I</b> prefix (of the interface) then we can logically expect the type to implement this interface. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#AvoidTypeInterfaceInconsistencyRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotPrefixEventsWithAfterOrBeforeRule">
		<name>DoNotPrefixEventsWithAfterOrBeforeRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Usability" />
		<description><![CDATA[This rule ensures that event names are not prefixed with <b>After</b> or <b>Before</b>. The .NET naming conventions recommend using a verb in the present and in the past tense. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#DoNotPrefixEventsWithAfterOrBeforeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotPrefixValuesWithEnumNameRule">
		<name>DoNotPrefixValuesWithEnumNameRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Usability" />
		<description><![CDATA[This rule checks for <b>enum</b> values that are prefixed with the enumeration type name. This is typical in C/C++ application but unneeded in .NET since the <b>enum</b> type name must be specified anyway when used. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#DoNotPrefixValuesWithEnumNameRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotUseReservedInEnumValueNamesRule">
		<name>DoNotUseReservedInEnumValueNamesRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Usability" />
		<description><![CDATA[This rule checks for enumerations that contain values named <b>reserved</b>. This practice, often seen in C/C++ sources, is not needed in .NET since adding new values will not normally break binary compatibility. However renaming a <b>reserved</b>enum value can since there is no way to prevent people from using the old value. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#DoNotUseReservedInEnumValueNamesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ParameterNamesShouldMatchOverriddenMethodRule">
		<name>ParameterNamesShouldMatchOverriddenMethodRule</name>
		<configKey><![CDATA[ParameterNamesShouldMatchOverriddenMethodRule@Gendarme.Rules.Naming.dll]]></configKey>
		<category name="Usability" />
		<description><![CDATA[This rule warns if an overriden method's parameter names does not match those of the base class or those of the implemented interface. This can be confusing because it may not always be clear that it is an override or implementation of an interface method. It also makes it more difficult to use the method with languages that support named parameters (like C# 4.0). <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#ParameterNamesShouldMatchOverriddenMethodRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseCorrectCasingRule">
		<name>UseCorrectCasingRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Usability" />
		<description><![CDATA[This rule ensures that identifiers are correctly cased. In particular: <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#UseCorrectCasingRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseCorrectPrefixRule">
		<name>UseCorrectPrefixRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Usability" />
		<description><![CDATA[This rule ensures that types are prefixed correctly. Interfaces should always be prefixed with a <b>I</b>, types should never be prefixed with a <b>C</b> (reminder for MFC folks) and generic parameters should be a single, uppercased letter or be prefixed with <b>T</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#UseCorrectPrefixRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseCorrectSuffixRule">
		<name>UseCorrectSuffixRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Usability" />
		<description><![CDATA[This rule ensure that types that inherit from certain types or implement certain interfaces have a specific suffix. It also ensures that no other types are using those suffixes without inheriting/implementing the types/interfaces. E.g. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#UseCorrectSuffixRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UsePluralNameInEnumFlagsRule">
		<name>UsePluralNameInEnumFlagsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Usability" />
		<description><![CDATA[This rule ensures that the name of enumerations decorated with FlagsAttribute are in plural form. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#UsePluralNameInEnumFlagsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UsePreferredTermsRule">
		<name>UsePreferredTermsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Usability" />
		<description><![CDATA[This rule ensures that identifiers such as assemblies, namespaces, types, and members, use the terms suggested by the .NET framework guidelines so that they are consistent with other class libraries. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#UsePreferredTermsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseSingularNameInEnumsUnlessAreFlagsRule">
		<name>UseSingularNameInEnumsUnlessAreFlagsRule</name>
		<configKey><![CDATA[UseSingularNameInEnumsUnlessAreFlagsRule@Gendarme.Rules.Naming.dll]]></configKey>
		<category name="Usability" />
		<description><![CDATA[The rule is used for ensure that the name of enumerations are in singular form unless the enumeration is used as flags, i.e. decorated with the <b>[Flags]</b> attribute. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Naming#UseSingularNameInEnumsUnlessAreFlagsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidLargeNumberOfLocalVariablesRule">
		<name>AvoidLargeNumberOfLocalVariablesRule</name>
		<configKey><![CDATA[AvoidLargeNumberOfLocalVariablesRule@Gendarme.Rules.Performance.dll]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule warns when the number of local variables exceed a maximum value (default is 64). Having a large amount of local variables makes it hard to generate code that performs well and, likely, makes the code harder to understand. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#AvoidLargeNumberOfLocalVariablesRule">Link to the official Mono Gendarme documentation</a>]]></description>
		<param key="MaximumVariables" type="i">
			<description><![CDATA[The maximum number of local variables which methods may have without a defect being reported. Default is 64.]]></description>

		</param>
	</rule>
	<rule key="AvoidLargeStructureRule">
		<name>AvoidLargeStructureRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule will fire if a value type (struct in C#) is larger than a maximum value (16 bytes by default). This is a problem because, unlike reference types, value types are bitwise-copied whenever they are assigned to a variable or passed to a method. If the type cannot be reduced in size then it should be turned into a reference type (class in C#). <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#AvoidLargeStructureRule">Link to the official Mono Gendarme documentation</a>]]></description>
		<param key="MaxSize" type="i">
			<description><![CDATA[The maximum size structs may be without a defect. Default is 16 (bit).]]></description>

		</param>
	</rule>
	<rule key="AvoidRepetitiveCastsRule">
		<name>AvoidRepetitiveCastsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule fires if multiple casts are done on the same value, for the same type. Casts are expensive so reducing them, by changing the logic or caching the result, can help performance. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#AvoidRepetitiveCastsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidReturningArraysOnPropertiesRule">
		<name>AvoidReturningArraysOnPropertiesRule</name>
		<configKey><![CDATA[AvoidReturningArraysOnPropertiesRule@Gendarme.Rules.Performance.dll]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule check for properties which return arrays. This can be a problem because properties are supposed to execute very quickly so it's likely that this property is returning a reference to the internal state of the object. This means that the caller can change the object's internal state via a back-door channel which is usually a very bad thing and it means that the array's contents may change unexpectedly if the caller holds onto the array. The preferred approach is to either return a read-only collection or to change the property to a method and return a copy of the array (it's important to use a method so that callers are not misled about the performance of the property). <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#AvoidReturningArraysOnPropertiesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidTypeGetTypeForConstantStringsRule">
		<name>AvoidTypeGetTypeForConstantStringsRule</name>
		<configKey><![CDATA[AvoidTypeGetTypeForConstantStringsRule@Gendarme.Rules.Performance.dll]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule warns when a method use <b>Type.GetType(string)</b> with a constant string. Such calls requires reflection in order to return a <b>Type</b> instance and, for known types, can be replaced with a much faster <b>typeof(x)</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#AvoidTypeGetTypeForConstantStringsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidUncalledPrivateCodeRule">
		<name>AvoidUncalledPrivateCodeRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule will check for internally visible methods which are never called. The rule will warn you if a private method isn't called in its declaring type or if an internal method doesn't have any callers in the assembly or isn't invoked by the runtime or a delegate. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#AvoidUncalledPrivateCodeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidUninstantiatedInternalClassesRule">
		<name>AvoidUninstantiatedInternalClassesRule</name>
		<configKey><![CDATA[AvoidUninstantiatedInternalClassesRule@Gendarme.Rules.Performance.dll]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule will fire if a type is only visible within its assembly, can be instantiated, but is not instantiated. Such types are often leftover (dead code) or are debugging/testing code and not required. However in some case the types might by needed, e.g. when accessed thru reflection or if the <b>[InternalsVisibleTo]</b> attribute is used on the assembly. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#AvoidUninstantiatedInternalClassesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidUnneededCallsOnStringRule">
		<name>AvoidUnneededCallsOnStringRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule detects when some methods, like <b>Clone()</b>, <b>Substring(0)</b>, <b>ToString()</b> or <b>ToString(IFormatProvider)</b>, are being called on a string instance. Since these calls all return the original string they don't do anything useful and should be carefully reviewed to see if they are working as intended and, if they are, the method call can be removed. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#AvoidUnneededCallsOnStringRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidUnneededFieldInitializationRule">
		<name>AvoidUnneededFieldInitializationRule</name>
		<configKey><![CDATA[AvoidUnneededFieldInitializationRule@Gendarme.Rules.Performance.dll]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule looks for constructors that assign fields to their default value (e.g. 0 for an integer, null for an object or a string). Since the CLR zero initializes all values there is no need, under most circumstances, to assign default values. Doing so only adds size to source code and in IL. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#AvoidUnneededFieldInitializationRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidUnneededUnboxingRule">
		<name>AvoidUnneededUnboxingRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule checks methods which unbox the same value type multiple times (i.e. the value is copied from the heap into the stack). Because the copy is relatively expensive, the code should be rewritten to minimize unboxes. For example, using a local variable of the right value type should remove the need for more than one unbox instruction per variable. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#AvoidUnneededUnboxingRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidUnsealedConcreteAttributesRule">
		<name>AvoidUnsealedConcreteAttributesRule</name>
		<configKey><![CDATA[AvoidUnsealedConcreteAttributesRule@Gendarme.Rules.Performance.dll]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule fires if an attribute is defined which is both concrete (i.e. not abstract) and unsealed. This is a performance problem because it means that <b>System.Attribute.GetCustomAttribute</b> has to search the attribute type hierarchy for derived types. To fix this either seal the type or make it abstract. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#AvoidUnsealedConcreteAttributesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidUnsealedUninheritedInternalTypeRule">
		<name>AvoidUnsealedUninheritedInternalTypeRule</name>
		<configKey><![CDATA[AvoidUnsealedUninheritedInternalTypeRule@Gendarme.Rules.Performance.dll]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule will fire for classes which are internal to the assembly and have no derived classes, but are not <b>sealed</b>. Sealing the type clarifies the type hierarchy and allows the compiler/JIT to perform optimizations such as eliding virtual method calls. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#AvoidUnsealedUninheritedInternalTypeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidUnusedParametersRule">
		<name>AvoidUnusedParametersRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule is used to ensure that all parameters in a method signature are being used. The rule wont report a defect against the following: <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#AvoidUnusedParametersRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidUnusedPrivateFieldsRule">
		<name>AvoidUnusedPrivateFieldsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule checks all private fields inside each type to see if some of them are not being used. This could be a leftover from debugging or testing code or a more serious typo where a wrong field is being used. In any case this makes the type bigger than it needs to be which can affect performance when a large number of instances exist. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#AvoidUnusedPrivateFieldsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="CompareWithEmptyStringEfficientlyRule">
		<name>CompareWithEmptyStringEfficientlyRule</name>
		<configKey><![CDATA[CompareWithEmptyStringEfficientlyRule@Gendarme.Rules.Performance.dll]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule will fire if a string is compared to <b>""</b> or <b>String.Empty</b>. Instead use a <b>String.Length</b> test which should be a bit faster. Another possibility (with .NET 2.0) is to use the static <b>String.IsNullOrEmpty</b> method. <b>String.IsNullOrEmpty</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#CompareWithEmptyStringEfficientlyRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ConsiderCustomAccessorsForNonVisibleEventsRule">
		<name>ConsiderCustomAccessorsForNonVisibleEventsRule</name>
		<configKey><![CDATA[ConsiderCustomAccessorsForNonVisibleEventsRule@Gendarme.Rules.Performance.dll]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule looks for non-visible events to see if their add/remove accessors are the default ones. The default, compiler generated, accessor is marked as synchronized which means that the runtime will bracket them between <b>Monitor.Enter</b> and <b>Monitor.Exit</b> calls. This is the safest approach unless, for non-visible events, you have a performance bottleneck around the events. In this case you should review if your code needs the locks or if you can provide an alternative to them. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#ConsiderCustomAccessorsForNonVisibleEventsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotIgnoreMethodResultRule">
		<name>DoNotIgnoreMethodResultRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule fires if a method is called that returns a new instance but that instance is not used. This is a performance problem because it is wasteful to create and collect objects which are never actually used. It may also indicate a logic problem. Note that this rule currently only checks methods within a small number of System types. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#DoNotIgnoreMethodResultRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ImplementEqualsTypeRule">
		<name>ImplementEqualsTypeRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule looks for types that override <b>Object.Equals(object)</b> but do not provide a <b>Equals(x)</b> overload using the type. Such an overload removes the need to cast the object to the correct type. For value types this also removes the costly boxing operations. Assemblies targeting .NET 2.0 (and later) should also implement <b>System.IEquatable&amp;lt;T&amp;gt;</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#ImplementEqualsTypeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MathMinMaxCandidateRule">
		<name>MathMinMaxCandidateRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule checks methods for code which seems to duplicate <b>Math.Min</b> or <b>Math.Max</b>. The JIT can inline these methods and generate better code for, at least some types, than it can for a custom inline implementation. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#MathMinMaxCandidateRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="OverrideValueTypeDefaultsRule">
		<name>OverrideValueTypeDefaultsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule checks all value types, except enumerations, to see if they use the default implementation of <b>Equals(object)</b> and <b>GetHashCode()</b> methods. While <b>ValueType</b> implementations work for any value type they do so at the expense of performance (the default implementation uses reflection to access fields). You can easily override both methods with much faster code since you know all meaningful fields inside your structure. At the same time you should also provide, if your language allows it, operator overloads for equality (<b>op_Equality</b>, <b>==</b>) and inequality (<b>op_Inequality</b>, <b>!=</b>). <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#OverrideValueTypeDefaultsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="PreferCharOverloadRule">
		<name>PreferCharOverloadRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule looks for calls to <b>String</b> methods that use <b>String</b>parameters when a <b>Char</b> parameter could have been used. Using the <b>Char</b> overload is preferred because it will be faster. Note, however, that this may result in subtly different behavior on versions of .NET before 4.0: the string overloads do a culture based comparison using <b>CultureInfo.CurrentCulture</b> and the char methods do an ordinal comparison (a simple compare of the character values). This can result in a change of behavior (for example the two can produce different results when precomposed characters are used). If this is important it is best to use an overload that allows StringComparison or CultureInfo to be explicitly specified see <a href="http://msdn.microsoft.com/en-us/library/ms973919.aspx#stringsinnet20_topic4" class="external" title="http://msdn.microsoft.com/en-us/library/ms973919.aspx#stringsinnet20 topic4" rel="nofollow">[1]</a><span class="urlexpansion">&amp;nbsp;(<i>http://msdn.microsoft.com/en-us/library/ms973919.aspx#stringsinnet20_topic4</i>)</span>  for more details. With .NET 4.0 <b>String'</b>s behavior will change and the various methods will be made more consistent. In particular the comparison methods will be changed so that they all default to doing an ordinal comparison. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#PreferCharOverloadRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="PreferLiteralOverInitOnlyFieldsRule">
		<name>PreferLiteralOverInitOnlyFieldsRule</name>
		<configKey><![CDATA[PreferLiteralOverInitOnlyFieldsRule@Gendarme.Rules.Performance.dll]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule looks for <b>InitOnly</b> fields (<b>readonly</b> in C#) that could be turned into <b>Literal</b> (<b>const</b> in C#) because their value is known at compile time. <b>Literal</b> fields don't need to be initialized (i.e. they don't force the compiler to add a static constructor to the type) resulting in less code and the value (not a reference to the field) will be directly used in the IL (which is OK if the field has internal visibility, but is often problematic if the field is visible outside the assembly). <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#PreferLiteralOverInitOnlyFieldsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="RemoveUnneededFinalizerRule">
		<name>RemoveUnneededFinalizerRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule looks for types that have an empty finalizer (a.k.a. destructor in C# or <b>Finalize</b> method). Finalizers that simply set fields to null are considered to be empty because this does not help the garbage collection. You should remove the empty finalizer to alleviate pressure on the garbage collector and finalizer thread. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#RemoveUnneededFinalizerRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="RemoveUnusedLocalVariablesRule">
		<name>RemoveUnusedLocalVariablesRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule looks for unused local variables inside methods. This can leads to larger code (IL) size and longer JIT time, but note that some optimizing compilers can remove the locals so they won't be reported even if you can still see them in the source code. This could also be a typo in the source were a value is assigned to the wrong variable. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#RemoveUnusedLocalVariablesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ReviewLinqMethodRule">
		<name>ReviewLinqMethodRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[Linq extension methods operate on sequences of values so they generally have linear time complexity. However you may be able to achieve better than linear time performance if you use a less general method or take advantage of a method provided by an <b>Sytem.Collections.Generic.IEnumerable&amp;lt;T&amp;gt;</b>  subclass. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#ReviewLinqMethodRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseIsOperatorRule">
		<name>UseIsOperatorRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule looks for complex cast operations (e.g. a <b>as</b>with a <b>null</b> check) that can be simplified using the <b>is</b> operator (C# syntax). Note: in some case a compiler, like [g]mcs, can optimize the code and generate IL identical to a <b>is</b> operator. In this case the rule will not report an error even if you could see one while looking the at source code. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#UseIsOperatorRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseStringEmptyRule">
		<name>UseStringEmptyRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule checks for methods that are using the literal <b>""</b> instead of the <b>String.Empty</b> field. You'll get slighly better performance by using <b>String.Empty</b>. Note that in some cases, e.g. in a <b>switch/case</b> statement, you cannot use a field, so <b>""</b> must be used instead of <b>String.Empty</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#UseStringEmptyRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseSuppressFinalizeOnIDisposableTypeWithFinalizerRule">
		<name>UseSuppressFinalizeOnIDisposableTypeWithFinalizerRule</name>
		<configKey><![CDATA[UseSuppressFinalizeOnIDisposableTypeWithFinalizerRule@Gendarme.Rules.Performance.dll]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule will fire if a type implements <b>System.IDisposable</b> and has a finalizer (called a destructor in C#), but the Dispose method does not call <b>System.GC.SuppressFinalize</b>. Failing to do this should not cause properly written code to fail, but it does place a non-trivial amount of extra pressure on the garbage collector and on the finalizer thread. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#UseSuppressFinalizeOnIDisposableTypeWithFinalizerRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseTypeEmptyTypesRule">
		<name>UseTypeEmptyTypesRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Efficiency" />
		<description><![CDATA[This rule fires if a zero length array of <b>System.Type</b> is created. This value is so often required by the framework API that the <b>System.Type</b> includes an <b>EmptyTypes</b> field. Using this field avoids the memory allocation (and GC tracking) of your own array. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Performance#UseTypeEmptyTypesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotHardcodePathsRule">
		<name>DoNotHardcodePathsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Portability" />
		<description><![CDATA[This rule checks for strings that contain valid paths, either under Unix or Windows file systems. Path literals are often not portable across operating systems (e.g. different path separators). To ensure correct cross-platform functionality they should be replaced by calls to <b>Path.Combine</b> and/or <b>Environment.GetFolderPath</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Portability#DoNotHardcodePathsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ExitCodeIsLimitedOnUnixRule">
		<name>ExitCodeIsLimitedOnUnixRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Portability" />
		<description><![CDATA[This rule applies to all executable (i.e. EXE) assemblies. Something that many Windows developers might not be aware of is that on Unix systems, process exit code must be between zero and 255, unlike in Windows where it can be any valid integer value. This rule warns if the returned value might be out of range either by: <br/><a href="http://www.mono-project.com/Gendarme.Rules.Portability#ExitCodeIsLimitedOnUnixRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="FeatureRequiresRootPrivilegeOnUnixRule">
		<name>FeatureRequiresRootPrivilegeOnUnixRule</name>
		<configKey><![CDATA[FeatureRequiresRootPrivilegeOnUnixRule@Gendarme.Rules.Portability.dll]]></configKey>
		<category name="Portability" />
		<description><![CDATA[This rule fires if a feature is used which is, by default, restricted under Unix. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Portability#FeatureRequiresRootPrivilegeOnUnixRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MonoCompatibilityReviewRule">
		<name>MonoCompatibilityReviewRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Portability" />
		<description><![CDATA[This rule will fire if one of the assemblies being checked contains a call to a .NET method which is either not implemented on Mono or partially implemented. It does this by downloading a MoMA definitions file under <b>~/.local/share/Gendarme/</b> (on UNIX) or <b>C:\Documents and Settings\{username}\Local Settings\Application Data\Gendarme</b> (on Windows) and checking for calls to the methods therein. The rule will work without MoMA but if it does fire it may be useful to download and run MoMA. By default the rule will use the latest local version available. This can be overriden to use a specific, local, version if you want to review compatibility against a specific Mono version. You can also manually remove them, now and then, to ensure you are using the latest version. Also upgrading Gendarme will try to download a newer version of the definitions files. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Portability#MonoCompatibilityReviewRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="NewLineLiteralRule">
		<name>NewLineLiteralRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Portability" />
		<description><![CDATA[This rule warns if methods, including properties, are using the literal <b>\r</b> and/or <b>\n</b> for new lines. This isn't portable across operating systems. To ensure correct cross-platform functionality they should be replaced by <b>System.Environment.NewLine</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Portability#NewLineLiteralRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ArrayFieldsShouldNotBeReadOnlyRule">
		<name>ArrayFieldsShouldNotBeReadOnlyRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule warns if a type declares a public <b>readonly</b> array field. Marking a field <b>readonly</b> only prevents the field from being assigned a different value, the object itself can still be changed. This means, that the elements inside the array can still be changed. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Security#ArrayFieldsShouldNotBeReadOnlyRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotShortCircuitCertificateCheckRule">
		<name>DoNotShortCircuitCertificateCheckRule</name>
		<configKey><![CDATA[DoNotShortCircuitCertificateCheckRule@Gendarme.Rules.Security.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule checks for methods that implements pass-through certificate checks. I.e. methods that override the framework decision about a certificate validity without checking anything specific about the supplied certificate or error code. Protocols like TLS/SSL are only secure if the certificates are used correctly. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Security#DoNotShortCircuitCertificateCheckRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="NativeFieldsShouldNotBeVisibleRule">
		<name>NativeFieldsShouldNotBeVisibleRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule checks if a class exposes native fields. Native fields should not be public because you lose control over their lifetime (other code could free the memory or use it after it has been freed). <br/><a href="http://www.mono-project.com/Gendarme.Rules.Security#NativeFieldsShouldNotBeVisibleRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="StaticConstructorsShouldBePrivateRule">
		<name>StaticConstructorsShouldBePrivateRule</name>
		<configKey><![CDATA[StaticConstructorsShouldBePrivateRule@Gendarme.Rules.Security.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule will fire if a type's static constructor is not private. This is a problem because the static constructor is meant to be called by the runtime but if it is not private then other code may call it as well which may lead to security vulnerabilities. Note that C# and VB.NET enforce this rule. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Security#StaticConstructorsShouldBePrivateRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AddMissingTypeInheritanceDemandRule">
		<name>AddMissingTypeInheritanceDemandRule</name>
		<configKey><![CDATA[AddMissingTypeInheritanceDemandRule@Gendarme.Rules.Security.Cas.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[The rule checks for types that are not <b>sealed</b> but have a <b>LinkDemand</b>. In this case the type should also have an <b>InheritanceDemand</b> for the same permissions. An alternative is to seal the type. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Security.Cas#AddMissingTypeInheritanceDemandRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotExposeFieldsInSecuredTypeRule">
		<name>DoNotExposeFieldsInSecuredTypeRule</name>
		<configKey><![CDATA[DoNotExposeFieldsInSecuredTypeRule@Gendarme.Rules.Security.Cas.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[The rule checks for types that are secured by <b>Demand</b> or <b>LinkDemand</b>but also expose visible fields. Access to these fields is not covered by the declarative demands, opening potential security holes. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Security.Cas#DoNotExposeFieldsInSecuredTypeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotExposeMethodsProtectedByLinkDemandRule">
		<name>DoNotExposeMethodsProtectedByLinkDemandRule</name>
		<configKey><![CDATA[DoNotExposeMethodsProtectedByLinkDemandRule@Gendarme.Rules.Security.Cas.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule checks for visible methods that are less protected (i.e. lower security requirements) than the method they call. If the called methods are protected by a <b>LinkDemand</b> then the caller can be used to bypass security checks. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Security.Cas#DoNotExposeMethodsProtectedByLinkDemandRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DoNotReduceTypeSecurityOnMethodsRule">
		<name>DoNotReduceTypeSecurityOnMethodsRule</name>
		<configKey><![CDATA[DoNotReduceTypeSecurityOnMethodsRule@Gendarme.Rules.Security.Cas.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule checks for types that have declarative security permission which aren't a subset of the security permission of some of their methods. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Security.Cas#DoNotReduceTypeSecurityOnMethodsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ReviewSealedTypeWithInheritanceDemandRule">
		<name>ReviewSealedTypeWithInheritanceDemandRule</name>
		<configKey><![CDATA[ReviewSealedTypeWithInheritanceDemandRule@Gendarme.Rules.Security.Cas.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule checks for sealed types that have <b>InheritanceDemand</b> declarative security applied to them. Since those types cannot be inherited from the <b>InheritanceDemand</b> will never be executed by the runtime. Check if the permission is required and, if so, change the <b>SecurityAction</b> to the correct one. Otherwise remove the permission. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Security.Cas#ReviewSealedTypeWithInheritanceDemandRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ReviewSuppressUnmanagedCodeSecurityUsageRule">
		<name>ReviewSuppressUnmanagedCodeSecurityUsageRule</name>
		<configKey><![CDATA[ReviewSuppressUnmanagedCodeSecurityUsageRule@Gendarme.Rules.Security.Cas.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule fires if a type or method is decorated with the <b>[SuppressUnmanagedCodeSecurity]</b>attribute. This attribute reduces the security checks done when executing unmanaged code and its usage should be reviewed to confirm that no exploitable security holes are present. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Security.Cas#ReviewSuppressUnmanagedCodeSecurityUsageRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="SecureGetObjectDataOverridesRule">
		<name>SecureGetObjectDataOverridesRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule fires if a type implements <b>System.Runtime.Serialization.ISerializable</b>but the <b>GetObjectData</b> method is not protected with a <b>Demand</b> or <b>LinkDemand</b> for <b>SerializationFormatter</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Security.Cas#SecureGetObjectDataOverridesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="CallBaseMethodsOnISerializableTypesRule">
		<name>CallBaseMethodsOnISerializableTypesRule</name>
		<configKey><![CDATA[CallBaseMethodsOnISerializableTypesRule@Gendarme.Rules.Serialization.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule checks types that implement the <b>System.ISerializable</b> interface and fires if either the serialization constructor or the <b>GetObjectData</b>method does not call it's <b>base</b> type, potentially breaking the serialization process. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Serialization#CallBaseMethodsOnISerializableTypesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="DeserializeOptionalFieldRule">
		<name>DeserializeOptionalFieldRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule will fire if a type has fields marked with <b>[OptionalField]</b>, but does not have methods decorated with the <b>[OnDeserialized]</b> or <b>[OnDeserializing]</b> attributes. This is a problem because the binary deserializer does not actually construct objects (it uses <b>System.Runtime.Serialization.FormatterServices.GetUninitializedObject</b>instead). So, if binary deserialization is used the optional field(s) will be zeroed instead of properly initialized. This rule only applies to assemblies compiled with the .NET framework version 2.0 (or later). <br/><a href="http://www.mono-project.com/Gendarme.Rules.Serialization#DeserializeOptionalFieldRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="ImplementISerializableCorrectlyRule">
		<name>ImplementISerializableCorrectlyRule</name>
		<configKey><![CDATA[ImplementISerializableCorrectlyRule@Gendarme.Rules.Serialization.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule checks for types that implement <b>ISerializable</b>. Such types serialize their data by implementing <b>GetObjectData</b>. This rule verifies that every instance field, not decorated with the <b>[NonSerialized]</b>attribute is serialized by the <b>GetObjectData</b> method. This rule will also warn if the type is unsealed and the <b>GetObjectData</b> is not <b>virtual</b>. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Serialization#ImplementISerializableCorrectlyRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MarkAllNonSerializableFieldsRule">
		<name>MarkAllNonSerializableFieldsRule</name>
		<configKey><![CDATA[MarkAllNonSerializableFieldsRule@Gendarme.Rules.Serialization.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule checks for serializable types, i.e. decorated with the <b>[Serializable]</b>attribute, and checks to see if all its fields are serializable as well. If not the rule will fire unless the field is decorated with the <b>[NonSerialized]</b> attribute. The rule will also warn if the field type is an interface as it is not possible, before execution time, to know for certain if the type can be serialized or not. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Serialization#MarkAllNonSerializableFieldsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MarkEnumerationsAsSerializableRule">
		<name>MarkEnumerationsAsSerializableRule</name>
		<configKey><![CDATA[MarkEnumerationsAsSerializableRule@Gendarme.Rules.Serialization.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule warns when it founds an <b>enum</b> that is not decorated with a <b>[Serializable]</b> attribute. Enums, even without the attribute, are always serializable. Marking them as such makes the source code more readable. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Serialization#MarkEnumerationsAsSerializableRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MissingSerializableAttributeOnISerializableTypeRule">
		<name>MissingSerializableAttributeOnISerializableTypeRule</name>
		<configKey><![CDATA[MissingSerializableAttributeOnISerializableTypeRule@Gendarme.Rules.Serialization.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule checks for types that implement <b>System.ISerializable</b> but are not decorated with the <b>[Serializable]</b> attribute. Implementing <b>System.ISerializable</b> is not enough to make a class serializable as this interface only gives you more control over the basic serialization process. In order for the runtime to know your type is serializable it must have the <b>[Serializable]</b> attribute. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Serialization#MissingSerializableAttributeOnISerializableTypeRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="MissingSerializationConstructorRule">
		<name>MissingSerializationConstructorRule</name>
		<configKey><![CDATA[MissingSerializationConstructorRule@Gendarme.Rules.Serialization.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule checks for types that implement <b>System.ISerializable</b> but don't provide a serialization constructor. The constructor is required in order to make the type serializeable but cannot be enforced by the interface. The serialization constructor should be <b>private</b> for <b>sealed</b> types and <b>protected</b> for unsealed types. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Serialization#MissingSerializationConstructorRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseCorrectSignatureForSerializationMethodsRule">
		<name>UseCorrectSignatureForSerializationMethodsRule</name>
		<configKey><![CDATA[UseCorrectSignatureForSerializationMethodsRule@Gendarme.Rules.Serialization.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule checks for methods which use the serialization attributes: <b>[OnSerializing, OnDeserializing, OnSerialized, OnDeserialized]</b>. You must ensure that these methods have the correct signature. They should be <b>private</b>, return <b>void</b> and have a single parameter of type <b>StreamingContext</b>. Failure to have the right signature can, in some circumstances, make your assembly unusable at runtime. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Serialization#UseCorrectSignatureForSerializationMethodsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidCodeDuplicatedInSameClassRule">
		<name>AvoidCodeDuplicatedInSameClassRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for duplicated code in the same class. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Smells#AvoidCodeDuplicatedInSameClassRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidCodeDuplicatedInSiblingClassesRule">
		<name>AvoidCodeDuplicatedInSiblingClassesRule</name>
		<configKey><![CDATA[AvoidCodeDuplicatedInSiblingClassesRule@Gendarme.Rules.Smells.dll]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule looks for code duplicated in sibling subclasses. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Smells#AvoidCodeDuplicatedInSiblingClassesRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidLargeClassesRule">
		<name>AvoidLargeClassesRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule allows developers to measure the classes size. When a class is trying to doing a lot of work, then you probabily have the Large Class smell. This rule will fire if a type contains too many fields (over 25 by default) or has fields with common prefixes. If the rule does fire then the type should be reviewed to see if new classes should be extracted from it. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Smells#AvoidLargeClassesRule">Link to the official Mono Gendarme documentation</a>]]></description>
		<param key="MaxFields" type="i">
			<description><![CDATA[The maximum number of fields allowed. Default is 25.]]></description>
		</param>
	</rule>
	<rule key="AvoidLongMethodsRule">
		<name>AvoidLongMethodsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule allows developers to measure the method size. The short sized methods allows you to maintain your code better, if you have long sized methods perhaps you have the Long Method smell. The rule will skip some well known methods, because they are autogenerated: <br/><a href="http://www.mono-project.com/Gendarme.Rules.Smells#AvoidLongMethodsRule">Link to the official Mono Gendarme documentation</a>]]></description>
		<param key="MaxSourceLineOfCode" type="i">
			<description><![CDATA[The maximum number of LoC allowed. Default is 40.]]></description>
		</param>
	</rule>
	<rule key="AvoidLongParameterListsRule">
		<name>AvoidLongParameterListsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule allows developers to measure the parameter list size in a method. If you have methods with a lot of parameters, perhaps you have a Long Parameter List smell. This rule counts the method's parameters, and compares it against a maximum value. If you have an overloaded method, then the rule will get the shortest overload and compare the shortest overload against the maximum value. Other time, it's quite hard determine a long parameter list. By default, a method with 6 or more arguments will be flagged as a defect. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Smells#AvoidLongParameterListsRule">Link to the official Mono Gendarme documentation</a>]]></description>
		<param key="MaxParameters" type="i">
			<description><![CDATA[The maximum number of parameters allowed. Default is 6.]]></description>
		</param>
	</rule>
	<rule key="AvoidMessageChainsRule">
		<name>AvoidMessageChainsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for the Message Chain smell. This can cause problems because it means that your code is heavily coupled to the navigation structure. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Smells#AvoidMessageChainsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidSpeculativeGeneralityRule">
		<name>AvoidSpeculativeGeneralityRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule allows developers to avoid the Speculative Generality smell. Be careful if you are developing a new framework or a new library, because this rule only inspects the assembly, then if you provide an abstract base class for extend by third party people, then the rule can warn you. You can ignore the message in this special case. We detect this smell by looking for: <br/><a href="http://www.mono-project.com/Gendarme.Rules.Smells#AvoidSpeculativeGeneralityRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="AvoidSwitchStatementsRule">
		<name>AvoidSwitchStatementsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Maintainability" />
		<description><![CDATA[This rule checks for the Switch Statements smell. This can lead to code duplication, because the same switch could be repeated in various places in your program. Also, if need to do a little change, you may have to change every switch statement. The preferred way to do this is with virtual methods and polymorphism. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Smells#AvoidSwitchStatementsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="GtkSharpExecutableTargetRule">
		<name>GtkSharpExecutableTargetRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[An executable assembly, i.e. an .exe, refers to the gtk-sharp assembly but isn't compiled using <b>-target:winexe</b>. A console window will be created and shown under Windows (MS runtime) when the application is executed. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Ui#GtkSharpExecutableTargetRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="SystemWindowsFormsExecutableTargetRule">
		<name>SystemWindowsFormsExecutableTargetRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[An executable assembly, i.e. an .exe, refers to the System.Windows.Forms assembly but isn't compiled using <b>-target:winexe</b>. A console window will be created and shown under Windows (MS runtime) when the application is executed which is probably not desirable for a winforms application. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Ui#SystemWindowsFormsExecutableTargetRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>
	<rule key="UseSTAThreadAttributeOnSWFEntryPointsRule">
		<name>UseSTAThreadAttributeOnSWFEntryPointsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule checks executable assemblies, i.e. *.exe's, that reference System.Windows.Forms to ensure that their entry point is decorated with <b>[System.STAThread]</b> attribute and is not decorated with <b>[System.MTAThread]</b> attribute to ensure that Windows Forms work properly. <br/><a href="http://www.mono-project.com/Gendarme.Rules.Ui#UseSTAThreadAttributeOnSWFEntryPointsRule">Link to the official Mono Gendarme documentation</a>]]></description>
	</rule>


	<rule key="PreferParamsArrayForVariableArgumentsRule">
		<name>PreferParamsArrayForVariableArgumentsRule</name>
		<configKey><![CDATA[PreferParamsArrayForVariableArgumentsRule@Gendarme.Rules.BadPractice.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[The rule warns for any method that use the (semi-documented) <b>vararg</b> calling convention (e.g. <b>__arglist</b> in C#) and that is not used for interoperability (i.e. pinvoke to unmanaged code). Using <b>params</b> (C#) can to achieve the same objective while <b>vararg</b> is not CLS compliant. The later will limit the usability of the method to CLS compliant language (e.g. Visual Basic does not support <b>vararg</b>]]></description>
	</rule>
	<rule key="PreferTryParseRule">
		<name>PreferTryParseRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule will warn you if a method use a <b>Parse</b> method when an alternative <b>TryParse</b> method is available. A <b>Parser</b> method, when using correctly, requires you to deal with multiple exceptions (a complete list likely not easily available) or catching all exceptions (bad). Also the throwing/catching of exceptions can kill performance. The <b>TryParse</b> method allow simpler code without the performance penality.]]></description>
	</rule>

	<rule key="UseNoInliningWithGetCallingAssemblyRule">
		<name>UseNoInliningWithGetCallingAssemblyRule</name>
		<configKey><![CDATA[UseNoInliningWithGetCallingAssemblyRule@Gendarme.Rules.Correctness.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule warns when a method call <b>Assembly.GetCallingAssembly()</b> from a method that is not decorated with <b>[MethodImpl(MethodImplOptions.NoInlining)]</b>. Without this attribute the method could be inlined by the JIT. In this case the calling assembly would be the assembly of the caller (of the inlined method), which could be different than the assembly of the real, source-wise, caller to <b>Assembly.GetCallingAssembly</b>.]]></description>
	</rule>

	<rule key="ProvideTryParseAlternativeRule">
		<name>ProvideTryParseAlternativeRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule will warn on any type that provide <b>Parse(string...)</b> method(s) without supplying <b>TryParse</b> alternative method(s). Using a <b>TryParse</b> method is easier since it is less-error prone (no need to handle all possible exceptions) and remove the performance issue regarding throwing/catching exceptions.]]></description>
	</rule>

	<rule key="AvoidDeclaringCustomDelegatesRule">
		<name>AvoidDeclaringCustomDelegatesRule</name>
		<configKey><![CDATA[AvoidDeclaringCustomDelegatesRule@Gendarme.Rules.Design.Generic.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule will fire if custom delegates are defined when either pre-defined <pre>Action</pre>, <pre>Action&lt;T[,...]&gt;</pre> or <pre>Func&lt;[Tx,...]TResult&gt;</pre> could have been used. This rule applies only to code using the framework version 2.0 (or later).]]></description>
	</rule>

	<rule key="RemoveDependenceOnObsoleteCodeRule">
		<name>RemoveDependenceOnObsoleteCodeRule</name>
		<configKey><![CDATA[RemoveDependenceOnObsoleteCodeRule@Gendarme.Rules.Maintainability.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule will warn you if your code depends on (e.g. inherit, implement, call...) code that is decorated with the <b>[Obsolete]</b> attribute. Note that the rule does not report <b>[Obsolete]</b> types, methods... but only their use by your code.]]></description>
	</rule>

	<rule key="CentralizePInvokesIntoNativeMethodsTypeRule">
		<name>CentralizePInvokesIntoNativeMethodsTypeRule</name>
		<configKey><![CDATA[CentralizePInvokesIntoNativeMethodsTypeRule@Gendarme.Rules.Interoperability.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule will warn you if p/invoke declarations are found outside some specially named types. The convention makes it easier to know which type of security checks are done (at runtime) and how critical is a security audit for them. In all cases the type should not be visible (i.e. <b>internal</b> in C#) outside the assembly.]]></description>
	</rule>

	<rule key="AvoidConcatenatingCharsRule">
		<name>AvoidConcatenatingCharsRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule will warn you if boxing is used to concatenate a string since this will slow down your code and can be easily avoided. This often happen when concatenating <b>System.String</b> and <b>System.Char</b> values together. However the rule is not limited to check boxing on <b>System.Char</b> since compilers often transform a character into its integer value (e.g. 'a' == 61) and the same boxing issue exists on integers.]]></description>
	</rule>
	<rule key="AvoidLocalDataStoreSlotRule">
		<name>AvoidLocalDataStoreSlotRule</name>
		<configKey><![CDATA[[email protected]]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[This rule warns if a method use <b>LocalDataStoreSlot</b> to store or retrieve data from Thread or Context Local Storage. The faster alternative is to use <b>[ThreadStatic]</b> or <b>[ContextStatic]</b> attributes to avoid extra calls and typecasts. Also <b>[ThreadStatic]</b> is available on Silverlight while the <b>LocalDataStoreSlot</b> API are not.]]></description>
	</rule>
	<rule key="AvoidRepetitiveCallsToPropertiesRule">
		<name>AvoidRepetitiveCallsToPropertiesRule</name>
		<configKey><![CDATA[AvoidRepetitiveCallsToPropertiesRule@Gendarme.Rules.Performance.dll]]></configKey>
		<category name="Reliability" />
		<description><![CDATA[The rule warn if virtual, or unlikely to be inline-able, property getters are called several times by a method. In most cases repetitive calls simply requires more time without any gains since the result will always be identical. You should ignore the reported defects if a different value is expected each time the property is called (e.g. calling <b>DateTime.Now</b>).]]></description>
	</rule>

</rules>