Gendarme

This covers MonoCompatibilityReviewRule. -- Jesse

r140021 -- Jesse

The problem is that "breaking" is a core concept in FxCop: every rule includes a note about whether fixing the defect is likely to be a breaking change. So FxCop users are (for the most part) going to know what breaking means. I don't think this is true of Gendarme users, unless they are also FxCop users which we should not assume.

Please commit. Thanks! Sebastien

There was one back in 1.x days and MS provided the winchurn tool to compare assemblies. I have not seen this being updated (well I did not really look either) for 2.0 (e.g. generics). Yes. I like the extra details (the "why") and adding this reduce potential confusion unless we reuse the same terminology as MS (fxcop)

TBH I attempted to rewrite it in c#, couldn't quite get cecil to do what i expected and gave up. I'm being lazy and appealing to a higher power by writing this. In an effort to not be lazy, I'll have another stab at it!

This covers: AvoidLargeNumberOfLocalVariabl esRule AvoidLargeStructureRule AvoidUnsealedConcreteAttribute sRule AvoidUnusedParametersRule DontIgnoreMethodResultRule IDisposableWithDestructorWitho utSuppressFinalizeRule PreferCharOverloadRule -- Jesse

r139859 -- Jesse

Yeah, but what constitutes a breaking change is not easy to figure out. I don't think I have ever seen a document describing what its breaking and what is not breaking from the perspective of a C# coder for example. And even at the CLI level it's hard to find this out. Because of this I think it's useful to be clear about why the change

True, but that is always the case. E.g. if I remove (or rename) a visible method (or type) then it's only "breaking" if someone use it. Yet this is, in MS terminology, always a "breaking change" since the implied forward compatibility promise is ... [More] broken. This is a place where the "FX" in FxCop shows - it was designed to check *shared libraries* [Less]