You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The type system and metadata loader are in a quite unpolished state, despite being heart of the IR. These are some of the things which need to be improved/fixed.
Load rare but expansive properties on-demand: method bodies, custom attributes, type members, etc.
Retain missing metadata tables
Method PInvoke info
Embedded resources
Others?
Make most properties mutable
Consider supporting bridges for Cecil/dnlib/ AsmResolver Can't really think of many reasons for this, other than supporting obfuscated modules (which idk if they are worth bothering with). This would actually probably save a lot of work, in addition to support for the old framework crunk and obfuscated modules.
The problem with SRM is that it just gives out the raw metadata tables without much further structuring, so you inevitably need an abstraction over it. Plus, serializing modules back also takes a lot of work.
AsmResolver seems to be intended as a replacement for both Cecil and dnlib, which are kind of stagnated. Replacing the entirety of DistIL to use it sounds enticing at first, but it'd be certainly not fun to pull it off. It doesn't look as lightweight and convenient to use as our own, which is designed to be more like the reflection model rather than a metadata model, so I guess a bridge would indeed be an acceptable solution.
The text was updated successfully, but these errors were encountered:
There's still some cleanup left to do around lists and (immutable)arrays
and mutability in general, but there doesn't seem to be any breaks.
(I really need to get used to writing unit tests.)
Contributes to #29
The type system and metadata loader are in a quite unpolished state, despite being heart of the IR. These are some of the things which need to be improved/fixed.
Cecil/dnlib/AsmResolverCan't really think of many reasons for this, other than supporting obfuscated modules (which idk if they are worth bothering with).This would actually probably save a lot of work, in addition to support for the old framework crunk and obfuscated modules.The problem with SRM is that it just gives out the raw metadata tables without much further structuring, so you inevitably need an abstraction over it. Plus, serializing modules back also takes a lot of work.
AsmResolver seems to be intended as a replacement for both Cecil and dnlib, which are kind of stagnated. Replacing the entirety of DistIL to use it sounds enticing at first, but it'd be certainly not fun to pull it off. It doesn't look as lightweight and convenient to use as our own, which is designed to be more like the reflection model rather than a metadata model, so I guess a bridge would indeed be an acceptable solution.
The text was updated successfully, but these errors were encountered: