Remove type that is in use

[MeFisto94]

My bigger picture use-case is the following:

• I decompile a set of classes from an assembly.
• The classes' sourcecode can then be edited manually.
• The individual classes will be recompiled using the existing assemblies as references
• The class/type is swapped out in the assembly using cecil.

The problems now arise for me at the third step: If I want to compile class foo against a reference assembly that also contains a definition of foo, the compiler will emit a warning and especially error out when trying to cast the instances against each-other.
My simple solution would then be to just remove the type from the assembly during compilation (ModuleDefinition#Types#Remove(TypeDefinition))

My problem now is that cecil re-writes the whole assembly from it's internal representation, which makes it error out when other code in the assembly references the deleted type.

Is this just a problem of deleting the type "properly", so that it just cannot be resolved anymore?
I've seen two different stack traces, both around CodeReader#PatchRawCode, sometimes:

System.ArgumentNullException: Value cannot be null.
   at Mono.Cecil.MetadataBuilder.LookupToken(IMetadataTokenProvider provider)

sometimes it says that a specific member (method) would be used in a different module without importing.
That is the case when it could be looked up, but the modules are different (i.e. Module vs null, because the type is not part of the module anymore).

What can I do? Can I somehow make it use the "old" assembly when writing, so that it can read the type properly?
Basically cecil should probably just ignore call-sites or treat them as if the type was external (I can't add it to exportedtypes though).

Thanks in Advance for help!

[jbevain]

Hello,

Yes, as you say it's a matter of properly deleting the type, that is making sure that it's not in use anywhere else, otherwise when writing the assembly back you're going to get an exception.

I'm afraid there's nothing built-in to make this easier.

[MeFisto94]

What do you mean with "making sure that it's not in use anywhere else", though?
Especially because removing references would kind-of damage the whole code base, because when re-adding the class, I otherwise would need to re-construct the references again.

If I get that right, on the CIL level there are just method calls, no matter where that type comes from or where it is declared, so maybe I'd need a more unsafe library/approach when doing such hacks?

[jbevain]

Cecil provides an object model (a graph) representing an assembly. If you remove a Type from its collection of types, but the type is still used in a method body for instance (it could be used in many places of the object model), Cecil won't be able to write the assembly back.

Instead of removing a type, you could change it, or merge the type with another one. Again, there's nothing built-in for that, at the end of the day, Cecil is giving an object model from the assembly, it's on the user's responsibility to provide it with a valid object model to write back as an assembly.

[MeFisto94]

I've actually investigated the problem quite thoroughly now, and while it's a bit out of the scope of cecil, the issue basically is that the compiler doesn't see the assemblies as identical (the one that is used during compilation and the one of the dll that has been added as reference).
Thus, my only workaround/idea so far is stubbing away types where necessary, so they can be "safe removed" (renamed, in fact, because it's easier). This is because when force-removing a type, the compiler can't resolve method calls for methods that did contain the type as parameter.

Example:

class A {
 public void a() {
   B.b(this);
  }
}

class B {
  public static void b(A a, C c);
}

If I wanted to re-compile A here, I need to find any "outgoing" references to A (that is every method call, field, ..., that is of type A and that appears in the scope of the class A (and any other that may be re-compiled)).
Then I can add a stub of B to the compilation set (it only needs to contain every part that is referenced by A, because B's IL is discarded later, A's is not).

The good thing is, that I do not need to stub C, which can be taken from the assembly, unless A would also depend on C and e.g. calling new C(b);, then I'd also need to stub C. Manually, I could already get everything to working, but now I need Cecil to dynamically generate the stub classes.

Now the question:
Does Cecil provide an easy way of reverse-searching references? Something like Type.FindAllReferences() without manually having to iterate through every possibility (method parameters, fields, generics, method bodies, ...)

Thanks for your time already!