False
c:\program files\microsoft fxcop 1.30\Xml\FxCopReport.Xsl
True
True
100
10
C:\yole\mypal\OmniaMea\References\
- JetBrains.Omea.OpenAPI
- JetBrains.Omea.OpenAPI
- Omea
- OpenAPI
NoAttribute
- OpenAPI
- OpenAPI
- 1
- System.ArgumentException..ctor
- refId must be specified for Before and After anchors
- SetDisplayName
- url
- AbstractWebBrowser.Navigate(String url)
- url
- AbstractWebBrowser.NavigateInPlace(String url)
- CurrentUrl
- SetCommandProcessor
- SetCurrentUrl
- url
- ActionContext.SetCurrentUrl(String url)
- SetSelectedResourcesExpanded
- SetListOwner
- SetSelectedResources
- GetMinimumSize
- PluginLoader
- Plugin
- GetHelpKeyword
- VIEW_GOTO_ACTIONS
- VIEW_GOTO_ACTIONS
- ACTION_STANDARD_ACTIONS
- ACTION_STANDARD_ACTIONS
- TOOLS_OPTIONS_ACTIONS
- TOOLS_OPTIONS_ACTIONS
- ITEM_FIND_ACTIONS
- ITEM_FIND_ACTIONS
- VIEW_VIEWPANE_ACTIONS
- VIEW_VIEWPANE_ACTIONS
- ITEM_MODIFY_ACTIONS
- ITEM_MODIFY_ACTIONS
- GO_TAB_ACTIONS
- GO_TAB_ACTIONS
- ITEM_OPEN_ACTIONS
- ITEM_OPEN_ACTIONS
- theInstance
- PluginLoader
- Plugin
- SetActiveWorkspace
- ResourceListDelegate
- EditedResourceSavedDelegate
- ValidateStringDelegate
- validateErrorMessage
- validateErrorMessage
- validateErrorMessage
- ResourceDelegate
- GetAllWorkspaces
- text
- Text
- text
- Text
- WorkspaceFilterTypes
- WorkspaceFilterTypes
- ownerPlugin
- Plugin
- OwnerPluginLoaded
- Plugin
- displayName
- linkTooltip
- format
- GetControl
- GetSelectedPlainText
- text
- Text
- SetQuickFindResourceList
- url
- IResourceBrowser.ShowUrlBar(String url)
- IResourceTypeTabCollection
- CurrentUrl
- GetSelection
- IStringList
- SetViewsExclusive
- IPluginLoader
- Plugin
- GetPluginService
- Plugin
- GetViewsConstructors
- RegisterPluginService
- Plugin
- pluginService
- plugin
- isSingularTerm
- highlightDataProvider
- highlightDataProvider
- OwnerPluginLoaded
- Plugin
- IResourceList
- Deinstantiate
- Deinstantiate
- SortPropIDs
- SortDirections
- text
- Text
- text
- Text
- text
- Text
- text
- Text
- text
- Text
- text
- Text
- text
- Text
- presentation
- StopwordsInLastQuery
- Stopwords
- DefragmentIndex
- Defragment
- GetTermRecordMem
- Mem
- DumpIndexDefragmentationInfo
- Defragmentation
- NextUpdateFinishedEventHandler
- NextUpdateFinishedEventHandler
- NextUpdateFinishedEventHandler
- NextUpdateFinishedEventHandler
- NextUpdateFinishedEventHandler
- words
- IPlugin
- Plugin
- text
- Text
- ownerPlugin
- Plugin
- PropCharset
- Charset
- text
- Text
- text
- Text
- text
- Text
- ownerPlugin
- Plugin
- presentation
Default
- ConditionOp
- Op
Default
- ConditionOp.Eq
- Eq
- Eq
- Eq
Default
- ConditionOp.Gt
- Gt
- Gt
- Gt
Default
- ConditionOp.Lt
- Lt
- StartingPlugins
- Plugins
op_equality
- ColumnDescriptor
- PropNames
- Width
- CustomComparer
- Flags
- Int32.Parse(String s)
- Int32.Parse(String s, IFormatProvider provider)
- str
- str
- ColumnDescriptor
Equals
- ActionPresentation
op_equality
- ActionPresentation
Equals
- WordPtr
op_equality
- WordPtr
- StartOffset
- Section
- Text
Equals
- LinkChange
op_equality
- LinkChange
Assemblies specify permission requests
Permission requests prevent security exceptions from being thrown after code in an assembly has already begun executing. With permission requests, the assembly does not load if it has insufficient permissions. This rule will fire if you have specified a permission request incorrectly, or incompletely. If you have specified requests but FxCop reports a violation for this rule, use the PermView.exe tool to view the security permissions in the assembly. An unenforceable permission appears as an empty permission set.
You should add attributes specifying what permissions your assembly will demand, might demand, and what permissions it does not want granted. For example, the following attribute indicates that an assembly will, at minimum, require read access to the USERNAME environment variable: [assembly:EnvironmentPermissionAttribute(SecurityAction.RequestMinimum,
Read="USERNAME")]. To specify permissions that the assembly might demand, use SecurityAction.RequestOptional. To specify permissions that the assembly must not be granted, use SecurityAction.RequestRefuse.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/UsageRules/AssembliesPermissionRequests.html
askfxcop@microsoft.com
CriticalError
Assemblies have strong names
Assemblies with strong names can be placed in the global assembly cache and can be checked for tampering at run time.
The common language runtime compares the key in the assembly's manifest to the key used to generate the strong name, to ensure that the assembly's bits have not been tampered with.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/DesignRules/AssembliesHaveStrongNames.html
askfxcop@microsoft.com
Error
Assemblies should have the ComVisible attribute
The ComVisible attribute indicates whether COM clients can use the library. Good design dictates that developers explicitly indicate COM visibility.
The default value for this attribute is 'true'. However, the best design is to mark the assembly ComVisible false, and then marking types, interfaces, and individual members as ComVisible true, as appropriate. For more information, see the Design Guidelines section titled Exposing Functionality to COM.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/DesignRules/AssembliesShouldHaveComVisibleAttribute.html
askfxcop@microsoft.com
CriticalError, Error
Avoid creating static fields that are not constants
Static fields should be constant unless you carefully manage access to the field using locks.
Using static variables without making them thread safe can compromise execution state. This rule applies to managed code libraries. If the analyzed assembly is an application, it is usually safe to exclude violations of this rule.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/UsageRules/AvoidStaticNonConstants.html
askfxcop@microsoft.com
Warning
Avoid using out parameters
Using out parameters might indicate a design flaw.
Although there are legitimate times to use out parameters, their use frequently indicates a design that does not conform to the design guidelines for managed code.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/DesignRules/AvoidOutParms.html
askfxcop@microsoft.com
Warning
Avoid passing value types as ref (pointer) parameters
Using ref parameters with value types might indicate a design flaw.
Although there are legitimate times to use reference parameters for value types, their use frequently indicates a design that does not conform to the design guidelines for managed code.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/DesignRules/ValueNoByRef.html
askfxcop@microsoft.com
Warning
Collection names have the 'Collection' suffix
A type that extends Collection should be suffixed with 'Collection', as in StringCollection.
If a collection is a queue, it may also be suffixed with 'Queue', or if it is a stack, it may also be suffixed with 'Stack'. This is because these collections have semantic differences in use from other collections.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/NamingRules/CollectionNamesHaveCollectionSuffix.html
askfxcop@microsoft.com
Error
Consider overriding Equals and the equality operator on value types
The default System.ValueType implementation might not perform as well as a custom implementation.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/Performance/EqualsAndOperatorEqualsOnValueTypes.html
askfxcop@microsoft.com
Warning
Consider replacing methods with properties
Properties should be used instead of Get/Set methods in most situations.
Methods are preferable to properties in the following situations: the operation is a conversion, is expensive or has an observable side-effect; the order of execution is important; calling the member twice in succession creates different results; a member is static but returns a mutable value; or the member returns an array.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/DesignRules/ReplaceMethodsWithProps.html
askfxcop@microsoft.com
Warning
Delegate names do not have a 'Delegate' suffix
Do not use 'Delegate' as a suffix on a Delegate type's name.
Consider using Callback instead.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/NamingRules/DelegateNamesDoNotHaveDelegateSuffix.html
askfxcop@microsoft.com
Error
Do not pass literals where a localized string is expected
String literals that are embedded in source code are difficult to localize. Avoid passing string literals as arguments in circumstances where a localized string is generally expected.
Most localized applications, for example, should localize string arguments that are passed to exception constructors. When creating an Exception instance, therefore, a string argument retrieved from a string table is more appropriate than a string literal.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/Globalization/DoNotPassLiterals.html
askfxcop@microsoft.com
Error
The first parameter of an event is a System.Object type
By convention, .NET events have two parameters that specify the event sender and event data. Event handler signatures should follow this form: void MyEventHandler(object sender, EventArgs e).
The sender parameter is always of type System.Object, even if it is possible to employ a more specific type. Events that do not provide event data should use the System.EventHandler delegate type.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/DesignRules/EventFirstParmObject.html
askfxcop@microsoft.com
Error
The first parameter of an event is named 'sender'
By convention, .NET events have two parameters that specify the event sender and event data, as in void MyEventHandler(object sender, EventArgs e). The sender parameter is always of type object, even if it is possible to employ a more specific type.
Events that do not provide event data should use the System.EventHandler delegate type.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/NamingRules/EventFirstParametersHaveNameSender.html
askfxcop@microsoft.com
Error
The second parameter of an event is a System.EventArgs type
By convention, .NET events have two parameters that specify the event sender and event data. Event handler signatures should follow this form: void MyEventHandler(object sender, EventArgs e).
The 'e' parameter is always of type System.EventArgs. Events that do not provide event data should use the System.EventHandler delegate type.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/DesignRules/EventSecondParmEventArgs.html
askfxcop@microsoft.com
Error
The second parameter of an event is named 'e'
By convention, .NET events have two parameters that specify the event sender and event data, as in void MyEventHandler(object sender, EventArgs e). The state associated with the event is encapsulated in an instance of an EventArgs, named 'e'.
Events that do not provide event data should use the System.EventHandler delegate type.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/NamingRules/EventSecondParametersHaveNameE.html
askfxcop@microsoft.com
Error
Events have two parameters
By convention, .NET events have two parameters that specify the event sender and event data. Event handler signatures should follow this form: void MyEventHandler(object sender, EventArgs e).
Events that provide no event data should use the System.EventHandler delegate type.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/DesignRules/EventsHaveTwoParameters.html
askfxcop@microsoft.com
Error
IFormatProvider should be passed
If an overload exists that takes an IFormatProvider argument, it should always be called in favor of an overload that does not.
Some methods in the common language runtime convert a value to or from a string representation and take a string parameter that contains one or more characters, called format specifiers, which indicate how the value is to be converted. If the meaning of the format specifier varies by culture, a formatting object supplies the actual characters used in the string representation. In scenarios where sorting and comparison behavior should never change between cultures, specify CultureInfo.InvariantCulture.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/Globalization/IFormatProviderPassed.html
askfxcop@microsoft.com
Error
Member names do not contain underscores
Do not use underscores when specifying member names.
Some generated Visual Studio identifiers for applications contain underscore characters. Underscore characters should generally be avoided in public identifiers.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/NamingRules/MemberNamesDoNotHaveUnderscores.html
askfxcop@microsoft.com
Error
Member name acronyms of three or more characters are Pascal-cased
Acronyms of three or more letters should be Pascal-cased. For example, use XmlSpace rather than XMLSpace.
A violation of this rule might be required for compatibility with existing, non-managed symbol schemes. In general, however, these symbols should not be visible outside the assembly that uses them.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/NamingRules/MemberNamesAcronymsArePascalCased.html
askfxcop@microsoft.com
Error
Member name acronyms with two characters are all capitals
Two character acronyms should be in upper-case. For example, use System.IO instead of System.Io.
Although it may be common practice for some two character acronyms to not be fully capitalized, violations of this rule should not be excluded for this reason. For example, 'DbConnection', is common but incorrect; use DBConnection. A violation of this rule might be required for compatibility with existing, non-managed symbol schemes. In general, however, these symbols should not be visible outside the assembly that uses them.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/NamingRules/MemberNamesShortAcronymsCaps.html
askfxcop@microsoft.com
Error
Member names should consist of correctly spelled words
The individual words that make up a member name should not be abbreviated and should be spelled correctly.
If this rule generates a false positive on a term that should be recognized, add the word to the FxCop custom dictionary.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/UsageRules/MemberSpelling.html
askfxcop@microsoft.com
CriticalWarning
Namespace acronyms of three or more characters are Pascal-cased
Acronyms of three or more letters should be Pascal-cased. For example, use System.Xml rather than System.XML.
A violation of this rule might be required for compatibility with existing, non-managed symbol schemes. In general, however, these symbols should not be visible outside the assembly that uses them.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/NamingRules/NamespaceAcronymsNamesArePascalCased.html
askfxcop@microsoft.com
Error
Namespace names should consist of correctly spelled words
The individual words that make up a namespace should not be abbreviated and should be spelled correctly.
If this rule generates a false positive on a term that should be recognized, add the word to the FxCop custom dictionary.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/UsageRules/NamespaceSpelling.html
askfxcop@microsoft.com
CriticalWarning
Only collection names have the 'Collection' suffix
Types that do not extend Collection do not have the 'Collection' suffix.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/NamingRules/OnlyCollectionNamesHaveCollectionSuffix.html
askfxcop@microsoft.com
CriticalError
Parameter names do not match reserved keywords
Identifiers which match reserved keywords should be avoided. Matching is performed case-insensitively.
Names that describe the purpose or contents of a parameter are preferable to names that describe the data type or format. If a parameter has no descriptive information other than its type, use a generic name such as 'value'.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/NamingRules/ParameterNamesDoNotMatchKeywords.html
askfxcop@microsoft.com
Error
Parameter names should consist of correctly spelled words
The individual words that make up a parameter name should not be abbreviated and should be spelled correctly.
If this rule generates a false positive on a term that should be recognized, add the word to the FxCop custom dictionary.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/UsageRules/ParameterSpelling.html
askfxcop@microsoft.com
CriticalWarning
Properties that return collections should be read-only
Properties that return collections should be read-only so that users cannot entirely replace the backing store. Users can still modify the contents of the collection by calling relevant methods on the collection.
Note that the XmlSerializer class has special support for deserializing read-only collections. See the XmlSerializer overview for more information.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/UsageRules/PropertiesCollectionsReadOnly.html
askfxcop@microsoft.com
Warning
Properties should not return arrays
Properties that return arrays are prone to code inefficiencies.
Consider using a collection or making this a method. See the design guidelines for more information.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/Performance/PropertyArray.html
askfxcop@microsoft.com
Warning
Reference types are not passed as ref (pointer) parameters
Reference types are pointers by definition, so a ref parameter that takes a reference type is a double indirection (analogous to a 'double pointer' in C++). This design is inappropriate for most managed code scenarios.
Although there are legitimate times to use reference parameters for reference types, such use frequently indicates a design that does not conform to the design guidelines for managed code.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/DesignRules/RefTypeNotRefParm.html
askfxcop@microsoft.com
Warning
Type name acronyms with two characters are all capitals
Two character acronyms should be in upper-case. For example, use DBQuery instead of DbQuery.
Although it may be common practice for some two character acronyms to not be fully capitalized, violations of this rule should not be excluded for this reason. For example, 'DbConnection', is common but incorrect; use DBConnection. A violation of this rule might be required for compatibility with existing, non-managed symbol schemes. In general, however, these symbols should not be visible outside the assembly that uses them.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/NamingRules/TypeNamesShortAcronymsCaps.html
askfxcop@microsoft.com
Error
Type names should consist of correctly spelled words
The individual words that make up a type name should not be abbreviated and should be spelled correctly.
If this rule generates a false positive on a term that should be recognized, add the word to the FxCop custom dictionary.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/UsageRules/TypeSpelling.html
askfxcop@microsoft.com
CriticalWarning
Types do not have externally visible instance fields
Public or protected instance fields limit your ability to change the implementation details for those data items.
Use properties instead. They do not compromise usability or performance and they do provide flexibility in that they conceal the implementation details of the underlying data.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/DesignRules/TypesDoNotHavePublicInstanceFields.html
askfxcop@microsoft.com
Error
URI parameters should be of type System.Uri rather than string
If a parameter name contains "uri" or "url" or "urn", and it's typed as string, the parameter type should be changed to System.Uri, unless there is an overload method where the same parameter is typed as Uri.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/DesignRules/UriParametersShouldNotBeStrings.html
askfxcop@microsoft.com
Error
URI properties should be of type System.Uri rather than string
If a property name contains "uri" or "url" or "urn" and it's typed as string, it should be changed to System.Uri.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/DesignRules/UriPropertiesShouldNotBeStrings.html
askfxcop@microsoft.com
Error
Value types that override System.Object.Equals also implement the equality operator
Value types that redefine System.Object.Equals should redefine the equality operator as well to ensure that these members return the same results.
This helps ensure that types that rely on Equals (such as ArrayList and Hashtable) behave in a manner that is expected and consistent with the equality operator.
MS FxCopDev
http://www.gotdotnet.com/team/fxcop/docs/rules/UsageRules/ValueTypesEqualsOverridesRequireOperatorEqualsOverride.html
askfxcop@microsoft.com
Warning