That sucks. The old model of accessing references was much better for my scenario.
Maybe you can consider use cases such as mine and work some magic? :-) John On Jul 28, 5:36 pm, Jb Evain <[email protected]> wrote: > On Wed, Jul 28, 2010 at 1:37 PM, JohnC <[email protected]> wrote: > > I am writing a tool that takes a bunch of assemblies and changes the > > types and methods as per user-defined rules/conventions (say, all > > types derived from Form should be XXXForm). If the type/method changes > > in one assembly, the corresponding reference in other assemblies > > should change too. > > > --- > > > Unless there is an alternate way to change the references, iterating > > over all of them and changing them would really need the > > TypeReferences and MemberReferences API. It would be really great if > > you can add that. > > Iterating wouldn't really solve the issue, as it would have to return > a transient copy of a MemberReference, not the MemberReference used > itself in the assembly. > > Consider the case where you have a MemberReference: > > void System.Collections.Generic.List<!!0>::.ctor() > > !!0 is a mvar, which means it's a GenericParameter owned by a Method. > In the metadata GenericParameters are just indexed by position, in the > Cecil type system, it needs a context (a reference to the method which > defines !!0). > > So GetMemberReferences could return a transient copy of this ctor with > a declaring type instantiated with a dummy generic parameter, for the > sake of analyzing the methods that are referenced by a module, but if > you modify its name it won't modify the actual instantiations in the > assembly. > > So it's actually a bit tedious, but to do it properly you don't have > much choice but to visit the different elements of an assembly and the > IL bodies to do your remapping. > > -- > Jb Evain <[email protected]> -- -- mono-cecil
