[Mono-dev] corcompare - refactored to use Mono.Cecil instead of reflection

[Jb Evain]

Hey,

If the final decision is to keep you corcompare tool outside of the mcs 
tree until Cecil mature enough to be part of the tree itself, you're 
welcome to check-in your work in /cecil/corcompare.

Thanks,

Jb

Moty Mondiano wrote:
> Attached is a refactoring of corcompare to use Mono.Cecil.
> 
>  
> 
> We have tried to use corcompare on our mscorlib.dll (customized for
> Grasshopper and for running on Java). We tried running corcompare using
> Mono and also using MS .Net.
> 
> Because corcompare uses Reflection it refused to load our version of
> mscorlib.dll - enums and structs conflicted with the built in enums and
> structs. We believe that it will refuse to load a version of mscorlib
> other then the one it is running on.
> 
> We therefore chose to use Mono.Cecil instead of Reflection. The choice
> of Mono.Cecil is a natural choice in this context as it can load and
> analyze any assembly without side effects like the ones we saw.
> 
>  
> 
> As a result Corcompare is now:
> 
> 1.       Much faster (more likely to be used in the build system)
> 
> 2.       Can be used to load any version of mscorlib.
> 
> 3.       Does not run any static initializers 
> 
>  
> 
> Open Issue 1: Comparison of attribute values is now less accurate. Using
> Mono.Cecil we cannot evaluate the attribute but only examine how it was
> initialized. Therefore the following will be diagnosed as a difference:
> 
>             [MyAttribute("Value")] vs.
> 
>             [MyAttribute(MyProerty = "Value")]
> 
>  
> 
> Open Issue 2: How to resolve the build dependency on Mono.Cecil. Since
> now Corcompare uses Mono.Cecil.dll, I temporally added this compiler
> argument "-r:Mono.Cecil.dll" (i.e. it expects to find Mono.Cecil.dll in
> the current directory). Please advise on best practice to solve this
> dependency (for example should this makefile build Mono.Cecil.dll ?)
> 
>  
> 
> Thanks,
> 
> Moty Mondiano
> 
> Mainsoft Corporation
> 
> 
> 
>  
>