I claim this task.

The rule expects the moma files (expection.txt, missing.txt, monotodo.txt) in 
the
same directory. If one file is missing the other parts are still checked. (Is 
there a
way for rules to report general configuration errors to the runner?)

You could generate a Message with an error level. The trick is that it 
shouldn't be
reported for every method ;-) maybe you could add an IAssemblyRule interface 
that
would report this error only once per assembly analyzed.

[note: I'm taking a note about adding this feature, rule that can't initialized
properly, into a future version of Gendarme]

I don't have enough time to test the rule properly tonight but, from a quick 
look, I
think there's a bit of code duplication(*) to report warnings
(calledMethod.ToString() is also called very frequently). 

Speaking of warnings, I think that missing methods should be reported as Error 
(not
Warning) since they are more likely to crash (well throw a 
MissingMethodException) a
program using them.

(*) we got a rule to test this in the Smells category, you might want to run 
gendarme
on your rule to see the results (I'll do that eventually ;-)

more testing/comments later :)
Thanks!

* Added a one time warning for each missing file. (I hope the UnitTest is not 
too
messy :)).
* Only one ToString() call left.
* Missing methods are now reported as errors.

There is some code duplication, but most of it comes from small differences 
between
the rules (monotodo.txt includes comments and is stored inside a Dictionary,
exception.txt and missing.txt goes into a simple List).

Smells only says that my method is too long ;)

Ok, here are some ideas...

1) You should make WriteFileNotFoundWarning a property. That would be cleaner 
(since
it would be available, without reflection or using the directly the field) 
inside the
unit tests (and it's ok since it won't affect the runners anyway).

2) You should make NotImplemented, Missing and Todo properties too (no need to 
be
static since the rule is created a single time). Then, for the tests, you could
inherit from the rule to override the properties - and make them return some 
list
with "known" content (i.e. that will make the unit tests pass today and forever,
unlike the downloaded files which could require periodic updates).

3) You could copy-paste-adapt the web service code from MoMA to download, if not
already present on disk, the missing files. While a bit more complex, this would
totally *rule* ;-) Note that you may have to store them elsewhere since the 
gendarme
directory is probably not user-writable.

The last item could be a bit more complex, so don't hesitate to ask for help.

Placing an arbitrary due date for house keeping purposes, the task owner and 
claimee
can negotiate and change it if needed.

The UnitTests are cleaner now and inject some known content.

If one of the files is missing the rule will try to download the definition 
file.
Currently this is done purely in memory. I'll look into saving tomorrow :)

Using a special ctor for unit test is ok (I think it's been done before) but, 
in this
case, it's not as clean as what has been suggested (i.e. it wouldn't be needed 
if
virtual properties has been used). I'm not sure we have the rules yet, but 
having
public fields (instead of properties), should be flagged.

Now the big problem is that you're downloading a specific, for 1.2.6, zip file 
for
the definitions. This makes the rule works only for 1.2.6 (i.e. it won't work,
without updating the binary, for 1.2.7 or any future version of Mono). It's also
possible (even likely someday) that the Url won't be available anymore.

This can be solved by using the web service interface of MoMA to retrieve the 
latest
definitions available.

* The public fields are now properties and the special constructor is gone.
* The definitions zip file is cached locally.
* And the MoMA web service is being used to retrieve the latest uri of the 
definition
file.

MoMAWebService.cs is taken from trunk/moma/MoMA.Analyzer/Web
References/MoMAWebService/Reference.cs

I'll be on IRC for the next few hours.

Gendarme.Rules.Portability

MonoCompatibilityReviewRule 

This rule uses MoMA definition files to analyze assemblies and warns if methods 
are
called that:
* are marked with MonoTODO
* throw a NotImplementedException
* do not exist in the current version of mono

The rule looks for the definitions in ~/.local/share/Gendarme/definitions.zip. 
If the
file is missig, the current version is downloaded.

note: The goal of this rule isn't to replace MoMA (which is obviously the
easiest solution for Windows developers) but to help analyze multiple
portability issues from the Linux side (where Gendarme is most likely being
used).

This looks to be complete - but it will take me a bit of time to test properly 
(I'll
try to do this tomorrow but I got a few other things planned). 

Anyway as my quick tests seems ok, go ahead to claim another task (I'll ping 
you back
if there's a problem - or if I change anything).

Great work!
Sebastien

I made a few additional edits to the code to improve performance.
* The main change was to use Dictionaries instead of Lists for all three checks.
* I have also added the Initobj opcode. (as well as the unsafe opcodes Ldftn and
Ldvirtftn; MoMA checks those too.)
* Some reduction in code duplication.

Results:
From:
trunk/cecil/gendarme/bin/Mono.Cecil.dll - completed (73.695791 seconds).
To:
trunk/cecil/gendarme/bin/Mono.Cecil.dll - completed (1.238258 seconds).

small speedup:)

Note to self: hashtables ARE way more efficient than lists for lookups.

Andreas

Forgot the files...

Additional Note: MoMA uses SortedLists. In my tests SortedLists took around 2.3
seconds. You might want to point this out to the MoMA Team. (On Mono, could be 
that
SortedLists are faster on .Net)

A *very big* speed difference!

Committed to SVN r92017/8.

Great work :)
Sebastien