The four names above are not the only ones that this rule complains about. This violation was raised over my use of "Security" as an object name, saying that it conflicted "in part" with "System.Web.Security". I work in the financial trading industry where a "security" is something that can be traded, and it is something that I have to represent in my object model. There is no synonym that will be widely recognized by others who are using my code; and we don't use the Web namespace at all, so the chance for confusion is minimal. I love FxCop, but once again Microsoft shows its astounding arrogance: "For new development, there are no known scenarios where you must exclude a warning from this rule." Sorry guys, but you can't possibly predict all possible scenarios, and you should stop assuming that you can.

1) The type names under "Cause" should either list all names which the rule might complain about, or it should be changed to say "A type name matches a namespace name from the .NET Framework class library, such as..."

2) Under "When to Exclude Warnings," instead of the first sentence, it should say something like: "Duplicating namespace and object names could cause confusion and reduce the usability of your code. Before excluding a warning from this rule, carefully consider whether there is an alternate name you could use that would be less confusing."

It in fact seems that this rule is triggered whenever a class/type name is the same as the namespace it is contained in. For instance, I encountered this rule creating a type called "Documents" in a Xxx.Yyy.Documents namespace, and from a business point of view, naming the class "Documents" makes perfect sense (especially since this is a WCF service contract, where I want to make sure that the contract names make as much sense to the consumers as possible).

I would argue that the rule can be excluded in this case.